diff options
author | Christian Grothoff <christian@grothoff.org> | 2022-02-03 18:00:06 +0100 |
---|---|---|
committer | Christian Grothoff <christian@grothoff.org> | 2022-02-03 18:00:06 +0100 |
commit | dfc4d3f3c9e2bd17dd8fe38c4b10aaea45d5dab1 (patch) | |
tree | 132559469054777223f296e5d6803f0921f6e6d5 | |
parent | 81880ef835e9b0e4e7716cb77b24d14d7438c521 (diff) | |
download | lsd0001-dfc4d3f3c9e2bd17dd8fe38c4b10aaea45d5dab1.tar.gz lsd0001-dfc4d3f3c9e2bd17dd8fe38c4b10aaea45d5dab1.zip |
misc edits on security considerations
-rw-r--r-- | draft-schanzen-gns.xml | 128 |
1 files changed, 73 insertions, 55 deletions
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml index 98e540f..70c6209 100644 --- a/draft-schanzen-gns.xml +++ b/draft-schanzen-gns.xml | |||
@@ -2132,8 +2132,26 @@ NICK: john (Supplemental) | |||
2132 | </section> | 2132 | </section> |
2133 | <section anchor="security" numbered="true" toc="default"> | 2133 | <section anchor="security" numbered="true" toc="default"> |
2134 | <name>Security and Privacy Considerations</name> | 2134 | <name>Security and Privacy Considerations</name> |
2135 | <section anchor="security_crypto" numbered="true" toc="default"> | 2135 | <section anchor="security_availability" numbered="true" toc="default"> |
2136 | <name>Cryptography</name> | 2136 | <name>Availability</name> |
2137 | <t> | ||
2138 | In order to ensure availability of records beyond their | ||
2139 | absolute expiration times, implementations MAY allow to locally | ||
2140 | define relative expiration time values of records. | ||
2141 | Records can then be published recurringly with updated | ||
2142 | absolute expiration times by the implementation. | ||
2143 | </t> | ||
2144 | <t> | ||
2145 | Implementations MAY allow users to manage private records in | ||
2146 | their zones. | ||
2147 | Such private records should not be published in the storage, | ||
2148 | making their data completely unavailable to non-local users. | ||
2149 | Private records should still be considered just like | ||
2150 | regular records when resolving labels in local zones. | ||
2151 | </t> | ||
2152 | </section> | ||
2153 | <section anchor="security_agility" numbered="true" toc="default"> | ||
2154 | <name>Agility</name> | ||
2137 | <t> | 2155 | <t> |
2138 | The security of cryptographic systems depends on both the strength of | 2156 | The security of cryptographic systems depends on both the strength of |
2139 | the cryptographic algorithms chosen and the strength of the keys used | 2157 | the cryptographic algorithms chosen and the strength of the keys used |
@@ -2141,11 +2159,11 @@ NICK: john (Supplemental) | |||
2141 | of the protocol used by the system to ensure that there are no | 2159 | of the protocol used by the system to ensure that there are no |
2142 | non-cryptographic ways to bypass the security of the overall system. | 2160 | non-cryptographic ways to bypass the security of the overall system. |
2143 | This is why developers of applications managing GNS zones SHOULD | 2161 | This is why developers of applications managing GNS zones SHOULD |
2144 | select a default zone type considered secure at the time of | 2162 | select a default ztype considered secure at the time of |
2145 | releasing the software. | 2163 | releasing the software. |
2146 | For applications targeting end users that are not expected to | 2164 | For applications targeting end users that are not expected to |
2147 | understand cryptography, the application developer MUST NOT leave | 2165 | understand cryptography, the application developer MUST NOT leave |
2148 | the zone type selection of new zones to end users. | 2166 | the ztype selection of new zones to end users. |
2149 | </t> | 2167 | </t> |
2150 | <t> | 2168 | <t> |
2151 | This document concerns itself with the selection of cryptographic | 2169 | This document concerns itself with the selection of cryptographic |
@@ -2154,11 +2172,27 @@ NICK: john (Supplemental) | |||
2154 | broken (in the cryptographic sense) at the current time, and | 2172 | broken (in the cryptographic sense) at the current time, and |
2155 | cryptographic research so far leads us to believe that they are | 2173 | cryptographic research so far leads us to believe that they are |
2156 | likely to remain secure into the foreseeable future. However, this | 2174 | likely to remain secure into the foreseeable future. However, this |
2157 | isn't necessarily forever, and it is expected that new revisions of | 2175 | is not necessarily forever, and it is expected that new revisions of |
2158 | this document will be issued from time to time to reflect the current | 2176 | this document will be issued from time to time to reflect the current |
2159 | best practices in this area. | 2177 | best practices in this area. |
2160 | </t> | 2178 | </t> |
2161 | <t> | 2179 | <t> |
2180 | In terms of crypto-agility, whenever the need for an updated cryptographic | ||
2181 | scheme arises to, for example, replace ECDSA over Curve25519 for | ||
2182 | PKEY records it may simply be introduced | ||
2183 | through a new record type. Such a new record type may then replace | ||
2184 | the delegation record type for future records. | ||
2185 | The old record type remains | ||
2186 | and zones can iteratively migrate to the updated zone keys. | ||
2187 | To ensure that implementations correctly generate an error message | ||
2188 | when encountering a ztype that they do not support, | ||
2189 | current and future delegation records must always have the | ||
2190 | CRITICAL flag set. | ||
2191 | </t> | ||
2192 | </section> | ||
2193 | <section anchor="security_cryptography" numbered="true" toc="default"> | ||
2194 | <name>Cryptography</name> | ||
2195 | <t> | ||
2162 | GNS PKEY zone keys use ECDSA over Curve25519. | 2196 | GNS PKEY zone keys use ECDSA over Curve25519. |
2163 | This is an unconventional choice, | 2197 | This is an unconventional choice, |
2164 | as ECDSA is usually used with other curves. However, traditional | 2198 | as ECDSA is usually used with other curves. However, traditional |
@@ -2172,33 +2206,27 @@ NICK: john (Supplemental) | |||
2172 | keys fit into a single DNS label, which is good for usability. | 2206 | keys fit into a single DNS label, which is good for usability. |
2173 | </t> | 2207 | </t> |
2174 | <t> | 2208 | <t> |
2175 | In terms of crypto-agility, whenever the need for an updated cryptographic | ||
2176 | scheme arises to, for example, replace ECDSA over Curve25519 for | ||
2177 | PKEY records it may simply be introduced | ||
2178 | through a new record type. Such a new record type may then replace | ||
2179 | the delegation record type for future records. | ||
2180 | The old record type remains | ||
2181 | and zones can iteratively migrate to the updated zone keys. | ||
2182 | </t> | ||
2183 | <t> | ||
2184 | In order to ensure ciphertext indistinguishability, care must be | 2209 | In order to ensure ciphertext indistinguishability, care must be |
2185 | taken with respect to the initialization vector in the counter | 2210 | taken with respect to the initialization vector in the counter |
2186 | block. In our design, the IV is always the expiration time of the | 2211 | block. In our design, the IV is always the expiration time of the |
2187 | record block. | 2212 | record block. |
2188 | For blocks with relative expiration times it is implicitly | 2213 | When applications store records with relative expiration times, |
2189 | ensured that each time a block is published into the storage, its IV is | 2214 | monotonicity is implicitly |
2215 | ensured because each time a block is published into the storage, its IV is | ||
2190 | unique as the expiration time is calculated dynamically and increases | 2216 | unique as the expiration time is calculated dynamically and increases |
2191 | monotonically. | 2217 | monotonically with the system time. Still, |
2192 | The implementation MUST ensure that when relative expiration times | 2218 | an implementation MUST ensure that when relative expiration times |
2193 | are decreased that the expiration time of the next record block is | 2219 | are decreased, the expiration time of the next record block MUST |
2194 | always after the last published block. | 2220 | be after the last published block. |
2195 | For blocks with absolute expiration times, the implementation | 2221 | For records where an absolute expiration time is used, the implementation |
2196 | MUST ensure that the expiration time is increased when the record | 2222 | MUST ensure that the expiration time is always increased when the record |
2197 | data changes. For example, the expiration time may be increased | 2223 | data changes. For example, the expiration time on the wire may be increased |
2198 | by a single microsecond. | 2224 | by a single microsecond even if the user did not request a change. |
2199 | In case of deletion of all resource records under a label, the | 2225 | In case of deletion of all resource records under a label, the |
2200 | implementation MUST keep track of the last absolute expiration time | 2226 | implementation MUST keep track of the last absolute expiration time |
2201 | of the last published resource block. | 2227 | of the last published resource block. Implementations MAY use a PADDING |
2228 | record as a tombstone that preserves the last absolute expiration time, | ||
2229 | but then MUST take care to not publish a block with just a PADDING record. | ||
2202 | When new records are added under this label later, the implementation | 2230 | When new records are added under this label later, the implementation |
2203 | MUST ensure that the expiration times are after the last published | 2231 | MUST ensure that the expiration times are after the last published |
2204 | block. | 2232 | block. |
@@ -2232,9 +2260,9 @@ NICK: john (Supplemental) | |||
2232 | <name>Zone Management</name> | 2260 | <name>Zone Management</name> |
2233 | <t> | 2261 | <t> |
2234 | In GNS, zone administrators need to manage and protect their zone | 2262 | In GNS, zone administrators need to manage and protect their zone |
2235 | keys. Once a zone key is lost it cannot be recovered. Once it is | 2263 | keys. Once a zone key is lost, it cannot be recovered or revoked. |
2236 | compromised it cannot be revoked (unless a revocation message was | 2264 | Revocation messages may be pre-calculated if revocation is |
2237 | pre-calculated and is still available). | 2265 | required in case a zone key is lost. |
2238 | Zone administrators, and for GNS this includes end-users, are | 2266 | Zone administrators, and for GNS this includes end-users, are |
2239 | required to responsibly and diligently protect their cryptographic | 2267 | required to responsibly and diligently protect their cryptographic |
2240 | keys. | 2268 | keys. |
@@ -2262,42 +2290,29 @@ NICK: john (Supplemental) | |||
2262 | namespace for a particular name, but the implementation is not | 2290 | namespace for a particular name, but the implementation is not |
2263 | communicating with the storage and is hence unable to resolve it. | 2291 | communicating with the storage and is hence unable to resolve it. |
2264 | This situation is similar to a split-horizon DNS configuration. | 2292 | This situation is similar to a split-horizon DNS configuration. |
2265 | Which storages are implemented usually depend on the application | 2293 | Which storages are implemented usually depends on the application |
2266 | it is built for. | 2294 | it is built for. |
2267 | The storage used will most likely depend on the specific application | 2295 | The storage used will most likely depend on the specific application |
2268 | context using GNS resolution. | 2296 | context using GNS resolution. |
2269 | For example, one application may be the resolution of hidden services | 2297 | For example, one application may be the resolution of hidden services |
2270 | within the Tor network. | 2298 | within the Tor network, which may suggest using Tor routers for storage. |
2299 | <!-- FIXME: add non-normative reference to Tor / Tor hidden services here? --> | ||
2271 | Implementations of "aggregated" storages are conceivable, but | 2300 | Implementations of "aggregated" storages are conceivable, but |
2272 | are expected to be the exception. | 2301 | are expected to be the exception. |
2273 | </t> | 2302 | </t> |
2274 | <t> | ||
2275 | In order to ensure availability of records beyond their | ||
2276 | absolute expiration times, implementations MAY allow to locally | ||
2277 | define relative expiration time values of records. | ||
2278 | Records can then be published recurringly with updated | ||
2279 | absolute expiration times by the implementation. | ||
2280 | </t> | ||
2281 | <t> | ||
2282 | Implementations MAY allow users to manage private records in | ||
2283 | their zones. | ||
2284 | Such private records should not be published in the storage. | ||
2285 | Private records should still be considered just like | ||
2286 | regular records when resolving labels in local zones. | ||
2287 | </t> | ||
2288 | </section> | 2303 | </section> |
2289 | <section anchor="security_dht" numbered="true" toc="default"> | 2304 | <section anchor="security_dht" numbered="true" toc="default"> |
2290 | <name>Impact of DHTs as Underlying Storage</name> | 2305 | <name>Impact of DHTs as Underlying Storage</name> |
2291 | <t> | 2306 | <t> |
2292 | This document does not specify the properties of the underlying | 2307 | This document does not specify the properties of the underlying |
2293 | storage which is required by any GNS implementation. | 2308 | storage which is required by any GNS implementation. |
2294 | For implementers using a DHT as underlying storage, it is important | 2309 | It is important to note that the properties of the underlying |
2295 | to note that the properties of the DHT are directly inherited by the | 2310 | storage are directly inherited by the |
2296 | GNS implementation. This includes both security as well as | 2311 | GNS implementation. This includes both security as well as |
2297 | other non-functional properties such as scalability and performance. | 2312 | other non-functional properties such as scalability and performance. |
2298 | Implementers should take great care when selecting or implementing | 2313 | Implementers should take great care when selecting or implementing |
2299 | a DHT for use in a GNS implementation. | 2314 | a DHT for use as storage in a GNS implementation. |
2300 | DHTs with strong security and performance guarantees exist | 2315 | DHTs with reasonable security and performance properties exist |
2301 | <xref target="R5N"/>. | 2316 | <xref target="R5N"/>. |
2302 | It should also be taken into consideration that GNS implementations | 2317 | It should also be taken into consideration that GNS implementations |
2303 | which build upon different DHT overlays are unlikely to be | 2318 | which build upon different DHT overlays are unlikely to be |
@@ -2308,18 +2323,19 @@ NICK: john (Supplemental) | |||
2308 | <name>Revocations</name> | 2323 | <name>Revocations</name> |
2309 | <t> | 2324 | <t> |
2310 | Zone administrators are advised to pre-generate zone revocations | 2325 | Zone administrators are advised to pre-generate zone revocations |
2311 | and securely store the revocation information in case the zone | 2326 | and to securely store the revocation information in case the zone |
2312 | key is lost, compromised or replaced in the future. | 2327 | key is lost, compromised or replaced in the future. |
2313 | Pre-calculated revocations may become invalid due to expirations | 2328 | Pre-calculated revocations may become invalid due to expirations |
2314 | or protocol changes such as epoch adjustments. | 2329 | or protocol changes such as epoch adjustments. |
2315 | Consequently, implementers and users must make precautions in order | 2330 | Consequently, implementers and users must take precautions in order |
2316 | to manage revocations accordingly. | 2331 | to manage revocations accordingly. |
2317 | </t> | 2332 | </t> |
2318 | <t> | 2333 | <t> |
2319 | Revocation payloads do NOT include a 'new' key for key replacement. | 2334 | Revocation payloads do NOT include a 'new' key for key replacement. |
2320 | Inclusion of such a key would have two major disadvantages: | 2335 | Inclusion of such a key would have two major disadvantages: |
2321 | </t> | 2336 | </t> |
2322 | <t> | 2337 | <ol> |
2338 | <li> | ||
2323 | If revocation is used after a private key was compromised, | 2339 | If revocation is used after a private key was compromised, |
2324 | allowing key replacement would be dangerous: if an | 2340 | allowing key replacement would be dangerous: if an |
2325 | adversary took over the private key, the adversary could then | 2341 | adversary took over the private key, the adversary could then |
@@ -2327,8 +2343,8 @@ NICK: john (Supplemental) | |||
2327 | the compromised owner would have no chance to issue even a | 2343 | the compromised owner would have no chance to issue even a |
2328 | revocation. Thus, allowing a revocation message to replace a private | 2344 | revocation. Thus, allowing a revocation message to replace a private |
2329 | key makes dealing with key compromise situations worse. | 2345 | key makes dealing with key compromise situations worse. |
2330 | </t> | 2346 | </li> |
2331 | <t> | 2347 | <li> |
2332 | Sometimes, key revocations are used with the objective of changing | 2348 | Sometimes, key revocations are used with the objective of changing |
2333 | cryptosystems. Migration to another cryptosystem by replacing keys | 2349 | cryptosystems. Migration to another cryptosystem by replacing keys |
2334 | via a revocation message would only be secure as long as both | 2350 | via a revocation message would only be secure as long as both |
@@ -2338,7 +2354,8 @@ NICK: john (Supplemental) | |||
2338 | migration would conclude by revoking the legacy zone key only once | 2354 | migration would conclude by revoking the legacy zone key only once |
2339 | it is deemed no longer secure, and hopefully after most users have | 2355 | it is deemed no longer secure, and hopefully after most users have |
2340 | migrated to the replacement. | 2356 | migrated to the replacement. |
2341 | </t> | 2357 | </li> |
2358 | </ol> | ||
2342 | </section> | 2359 | </section> |
2343 | <section anchor="privacy_labels" numbered="true" toc="default"> | 2360 | <section anchor="privacy_labels" numbered="true" toc="default"> |
2344 | <name>Label Guessing</name> | 2361 | <name>Label Guessing</name> |
@@ -2361,7 +2378,8 @@ NICK: john (Supplemental) | |||
2361 | It should be noted that this attack on labels only applies if the | 2378 | It should be noted that this attack on labels only applies if the |
2362 | zone key is somehow disclosed to the adversary. GNS itself | 2379 | zone key is somehow disclosed to the adversary. GNS itself |
2363 | does not disclose it during a lookup or when resource records are | 2380 | does not disclose it during a lookup or when resource records are |
2364 | published as the zone keys are blinded beforehand. | 2381 | published as the zone keys are blinded beforehand. However, |
2382 | zone keys do become public during revocation. | ||
2365 | </t> | 2383 | </t> |
2366 | </section> | 2384 | </section> |
2367 | </section> | 2385 | </section> |