commit dfc4d3f3c9e2bd17dd8fe38c4b10aaea45d5dab1
parent 81880ef835e9b0e4e7716cb77b24d14d7438c521
Author: Christian Grothoff <christian@grothoff.org>
Date: Thu, 3 Feb 2022 18:00:06 +0100
misc edits on security considerations
Diffstat:
1 file changed, 73 insertions(+), 55 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -2132,8 +2132,26 @@ NICK: john (Supplemental)
</section>
<section anchor="security" numbered="true" toc="default">
<name>Security and Privacy Considerations</name>
- <section anchor="security_crypto" numbered="true" toc="default">
- <name>Cryptography</name>
+ <section anchor="security_availability" numbered="true" toc="default">
+ <name>Availability</name>
+ <t>
+ In order to ensure availability of records beyond their
+ absolute expiration times, implementations MAY allow to locally
+ define relative expiration time values of records.
+ Records can then be published recurringly with updated
+ absolute expiration times by the implementation.
+ </t>
+ <t>
+ Implementations MAY allow users to manage private records in
+ their zones.
+ Such private records should not be published in the storage,
+ making their data completely unavailable to non-local users.
+ Private records should still be considered just like
+ regular records when resolving labels in local zones.
+ </t>
+ </section>
+ <section anchor="security_agility" numbered="true" toc="default">
+ <name>Agility</name>
<t>
The security of cryptographic systems depends on both the strength of
the cryptographic algorithms chosen and the strength of the keys used
@@ -2141,11 +2159,11 @@ NICK: john (Supplemental)
of the protocol used by the system to ensure that there are no
non-cryptographic ways to bypass the security of the overall system.
This is why developers of applications managing GNS zones SHOULD
- select a default zone type considered secure at the time of
+ select a default ztype considered secure at the time of
releasing the software.
For applications targeting end users that are not expected to
understand cryptography, the application developer MUST NOT leave
- the zone type selection of new zones to end users.
+ the ztype selection of new zones to end users.
</t>
<t>
This document concerns itself with the selection of cryptographic
@@ -2154,11 +2172,27 @@ NICK: john (Supplemental)
broken (in the cryptographic sense) at the current time, and
cryptographic research so far leads us to believe that they are
likely to remain secure into the foreseeable future. However, this
- isn't necessarily forever, and it is expected that new revisions of
+ is not necessarily forever, and it is expected that new revisions of
this document will be issued from time to time to reflect the current
best practices in this area.
</t>
<t>
+ In terms of crypto-agility, whenever the need for an updated cryptographic
+ scheme arises to, for example, replace ECDSA over Curve25519 for
+ PKEY records it may simply be introduced
+ through a new record type. Such a new record type may then replace
+ the delegation record type for future records.
+ The old record type remains
+ and zones can iteratively migrate to the updated zone keys.
+ To ensure that implementations correctly generate an error message
+ when encountering a ztype that they do not support,
+ current and future delegation records must always have the
+ CRITICAL flag set.
+ </t>
+ </section>
+ <section anchor="security_cryptography" numbered="true" toc="default">
+ <name>Cryptography</name>
+ <t>
GNS PKEY zone keys use ECDSA over Curve25519.
This is an unconventional choice,
as ECDSA is usually used with other curves. However, traditional
@@ -2172,33 +2206,27 @@ NICK: john (Supplemental)
keys fit into a single DNS label, which is good for usability.
</t>
<t>
- In terms of crypto-agility, whenever the need for an updated cryptographic
- scheme arises to, for example, replace ECDSA over Curve25519 for
- PKEY records it may simply be introduced
- through a new record type. Such a new record type may then replace
- the delegation record type for future records.
- The old record type remains
- and zones can iteratively migrate to the updated zone keys.
- </t>
- <t>
In order to ensure ciphertext indistinguishability, care must be
taken with respect to the initialization vector in the counter
block. In our design, the IV is always the expiration time of the
record block.
- For blocks with relative expiration times it is implicitly
- ensured that each time a block is published into the storage, its IV is
+ When applications store records with relative expiration times,
+ monotonicity is implicitly
+ ensured because each time a block is published into the storage, its IV is
unique as the expiration time is calculated dynamically and increases
- monotonically.
- The implementation MUST ensure that when relative expiration times
- are decreased that the expiration time of the next record block is
- always after the last published block.
- For blocks with absolute expiration times, the implementation
- MUST ensure that the expiration time is increased when the record
- data changes. For example, the expiration time may be increased
- by a single microsecond.
+ monotonically with the system time. Still,
+ an implementation MUST ensure that when relative expiration times
+ are decreased, the expiration time of the next record block MUST
+ be after the last published block.
+ For records where an absolute expiration time is used, the implementation
+ MUST ensure that the expiration time is always increased when the record
+ data changes. For example, the expiration time on the wire may be increased
+ by a single microsecond even if the user did not request a change.
In case of deletion of all resource records under a label, the
implementation MUST keep track of the last absolute expiration time
- of the last published resource block.
+ of the last published resource block. Implementations MAY use a PADDING
+ record as a tombstone that preserves the last absolute expiration time,
+ but then MUST take care to not publish a block with just a PADDING record.
When new records are added under this label later, the implementation
MUST ensure that the expiration times are after the last published
block.
@@ -2232,9 +2260,9 @@ NICK: john (Supplemental)
<name>Zone Management</name>
<t>
In GNS, zone administrators need to manage and protect their zone
- keys. Once a zone key is lost it cannot be recovered. Once it is
- compromised it cannot be revoked (unless a revocation message was
- pre-calculated and is still available).
+ keys. Once a zone key is lost, it cannot be recovered or revoked.
+ Revocation messages may be pre-calculated if revocation is
+ required in case a zone key is lost.
Zone administrators, and for GNS this includes end-users, are
required to responsibly and diligently protect their cryptographic
keys.
@@ -2262,42 +2290,29 @@ NICK: john (Supplemental)
namespace for a particular name, but the implementation is not
communicating with the storage and is hence unable to resolve it.
This situation is similar to a split-horizon DNS configuration.
- Which storages are implemented usually depend on the application
+ Which storages are implemented usually depends on the application
it is built for.
The storage used will most likely depend on the specific application
context using GNS resolution.
For example, one application may be the resolution of hidden services
- within the Tor network.
+ within the Tor network, which may suggest using Tor routers for storage.
+ <!-- FIXME: add non-normative reference to Tor / Tor hidden services here? -->
Implementations of "aggregated" storages are conceivable, but
are expected to be the exception.
</t>
- <t>
- In order to ensure availability of records beyond their
- absolute expiration times, implementations MAY allow to locally
- define relative expiration time values of records.
- Records can then be published recurringly with updated
- absolute expiration times by the implementation.
- </t>
- <t>
- Implementations MAY allow users to manage private records in
- their zones.
- Such private records should not be published in the storage.
- Private records should still be considered just like
- regular records when resolving labels in local zones.
- </t>
</section>
<section anchor="security_dht" numbered="true" toc="default">
<name>Impact of DHTs as Underlying Storage</name>
<t>
This document does not specify the properties of the underlying
storage which is required by any GNS implementation.
- For implementers using a DHT as underlying storage, it is important
- to note that the properties of the DHT are directly inherited by the
+ It is important to note that the properties of the underlying
+ storage are directly inherited by the
GNS implementation. This includes both security as well as
other non-functional properties such as scalability and performance.
Implementers should take great care when selecting or implementing
- a DHT for use in a GNS implementation.
- DHTs with strong security and performance guarantees exist
+ a DHT for use as storage in a GNS implementation.
+ DHTs with reasonable security and performance properties exist
<xref target="R5N"/>.
It should also be taken into consideration that GNS implementations
which build upon different DHT overlays are unlikely to be
@@ -2308,18 +2323,19 @@ NICK: john (Supplemental)
<name>Revocations</name>
<t>
Zone administrators are advised to pre-generate zone revocations
- and securely store the revocation information in case the zone
+ and to securely store the revocation information in case the zone
key is lost, compromised or replaced in the future.
Pre-calculated revocations may become invalid due to expirations
or protocol changes such as epoch adjustments.
- Consequently, implementers and users must make precautions in order
+ Consequently, implementers and users must take precautions in order
to manage revocations accordingly.
</t>
<t>
Revocation payloads do NOT include a 'new' key for key replacement.
Inclusion of such a key would have two major disadvantages:
</t>
- <t>
+ <ol>
+ <li>
If revocation is used after a private key was compromised,
allowing key replacement would be dangerous: if an
adversary took over the private key, the adversary could then
@@ -2327,8 +2343,8 @@ NICK: john (Supplemental)
the compromised owner would have no chance to issue even a
revocation. Thus, allowing a revocation message to replace a private
key makes dealing with key compromise situations worse.
- </t>
- <t>
+ </li>
+ <li>
Sometimes, key revocations are used with the objective of changing
cryptosystems. Migration to another cryptosystem by replacing keys
via a revocation message would only be secure as long as both
@@ -2338,7 +2354,8 @@ NICK: john (Supplemental)
migration would conclude by revoking the legacy zone key only once
it is deemed no longer secure, and hopefully after most users have
migrated to the replacement.
- </t>
+ </li>
+ </ol>
</section>
<section anchor="privacy_labels" numbered="true" toc="default">
<name>Label Guessing</name>
@@ -2361,7 +2378,8 @@ NICK: john (Supplemental)
It should be noted that this attack on labels only applies if the
zone key is somehow disclosed to the adversary. GNS itself
does not disclose it during a lookup or when resource records are
- published as the zone keys are blinded beforehand.
+ published as the zone keys are blinded beforehand. However,
+ zone keys do become public during revocation.
</t>
</section>
</section>
