commit 3321573836d5855abe95cb1f032acab12ad4b45b
parent f97871a7c27057449c446ea77189880c90e10f32
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Mon, 31 Jan 2022 18:12:06 +0100
Merge branch 'master' of ssh://git.gnunet.org/lsd0001
Diffstat:
1 file changed, 89 insertions(+), 69 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -183,7 +183,7 @@
A GNS label is a label as defined in <xref target="RFC8499"/>.
Within this document, labels are always assumed to be strings of
UTF-8 characters <xref target="RFC8499"/> with a maximum length of
- 63 bytes. When hashed, labels MUST be canonicalized using
+ 63 bytes. When hashed, labels MUST be canonicalized using
Normalization Form C (NFC) <xref target="Unicode-UAX15"/>.
</dd>
<dt>Name</dt>
@@ -195,26 +195,27 @@
</dd>
<dt>Top-Level Domain</dt>
<dd>
- A GNS Top-Level Domain is a GNS label and a Top-Level
- Domain (TLD) as defined in <xref target="RFC8499"/>.
- With the exception of Zone Top-Level Domains (see below),
- GNS TLDs are part of the configuration of the local resolver
- (see <xref target="governance"/>) and may not be globally unique.
+ The rightmost label in a GNS name is a GNS Top-Level Domain (TLD).
+ Unlike DNS Top-Level Domains (defined in <xref target="RFC8499"/>),
+ GNS does not expect all users to use the same global root zone. Instead,
+ with the exception of Zone Top-Level Domains (see below),
+ GNS TLDs are typically part of the configuration of the local resolver
+ (see <xref target="governance"/>), and may thus not be globally unique.
</dd>
<dt>Zone</dt>
<dd>
A GNS zone contains authoritative information (resource records).
- A zone is uniquely identified by its zone key.
+ A zone is uniquely identified by its zone key. Unlike DNS zones,
+ a GNS zone does not need to have a SOA record at its apex.
</dd>
<dt>Zone Type</dt>
<dd>
- The type of a GNS zone determines the format and type of the
- zone key.
+ The type of a GNS zone determines the cipher system and binary encoding
+ format of the zone key, blinded zone keys, and signatures.
</dd>
<dt>Zone Key</dt>
<dd>
The zone key uniquely identifies a zone.
- Its format and type depend on the associated zone type.
The zone key is usually a public key of an asymmetric key pair.
</dd>
<dt>Blinded Zone Key</dt>
@@ -224,16 +225,18 @@
</dd>
<dt>Zone Owner</dt>
<dd>
- The owner of a GNS zone is the holder of the private key corresponding to
- the respective zone key.
+ The owner of a GNS zone is the holder of the secret (typically a private key)
+ that (together with a label and a value to sign) allows the creation of zone
+ signatures that can be validated against the respective blinded zone key.
</dd>
<dt>Zone Top-Level Domain</dt>
<dd>
- A GNS Zone Top-Level Domain (zTLD) is a GNS name and a Top-Level
- Domain (TLD) as defined in <xref target="RFC8499"/>.
- It represents a sub-group of all TLDs and encodes the zone type and
+ A GNS Zone Top-Level Domain (zTLD) is a GNS label used as the
+ rightmost label in a GNS name which encodes a zone type and
zone key of a zone.
Due to the statistical uniqueness of zone keys, zTLDs are also globally unique.
+ A zTLD label can only be distinguished from ordinary TLD labels
+ by attempting to decode the label to a zone type and zone key.
</dd>
<dt>Resource Record</dt>
<dd>
@@ -252,13 +255,17 @@
Zones are uniquely identified by a zone key.
Zone contents are signed using blinded private keys and
encrypted using derived secret keys.
- The zone type determines the respectice set of cryptographic functions.
+ The zone type determines the respective set of cryptographic operations
+ and the wire formats for encrypted data, public keys and signatures.
</t>
<t>
A zone can be populated with mappings from labels to resource records by
its owner (<xref target="rrecords"/>).
- Labels can be delegated to other zones using delegation records and in
- order to support (legacy) applications as well as facilitate the use
+ A label can be mapped to a delegation record which results in the
+ corresponding subdomain being delegated to another zone. Circular
+ delegations are explicitly allowed, including delegating a subdomain
+ to its immediate parent zone. In
+ order to support (legacy) applications as well as to facilitate the use
of petnames, GNS defines auxiliary record types in addition to
supporting traditional DNS records.
</t>
@@ -268,31 +275,35 @@
(<xref target="publish"/>).
In this process, unique zone identification is hidden from the network
through the use of key blinding.
- It allows the creation of signatures for zone contents
+ Key blinding allows the creation of signatures for zone contents
using a blinded public/private key pair.
This blinding is realized using a deterministic key
derivation from
- the original zone key and corresponding private key using record label values.
- Specifically, the zone owner can derive private keys for each record
+ the original zone key and corresponding private key using record label values
+ as blinding factors.
+ Specifically, the zone owner can derive blinded private keys for each record
set published under a label, and a
- resolver can derive the corresponding public keys.
+ resolver can derive the corresponding blinded public keys.
It is expected that GNS implementations use distributed or decentralized
storages such as distributed hash tables (DHT) in order to facilitate
- availability within a network without the need of servers.
+ availability within a network without the need for dedicated infrastructure.
Specification of such a distributed or decentralized storage is out of
- scope of this document but possible existing implementations include those
+ scope of this document, but possible existing implementations include those
based on <xref target="RFC7363" />, <xref target="Kademlia" /> or
<xref target="R5N" />.
</t>
<t>
Names in GNS are domain names as defined in <xref target="RFC8499"/>.
- Starting from a configurable root zone, names are resolved following zone
- delegations which are recursively queried from the storage (<xref target="resolution"/>).
+ Starting from a configurable root zone, names are resolved by following zone
+ delegations. For each label in a name, the recursive GNS resolver
+ fetches the respective record from the storage layer (<xref target="resolution"/>).
Without knowledge of the label values and the zone keys, the
- different derived keys are unlinkable both to the original key and to each
+ different derived keys are unlinkable both to the original zone key and to each
other.
- This prevents zone enumeration and requires knowledge
- of both the zone key and the label to confirm affiliation with a
+ This prevents zone enumeration (except via impractical online brute
+ force attacks) and requires knowledge
+ of both the zone key and the label to confirm affiliation of a
+ query or the corresponding encrypted record set with a
specific zone. At the same time, the blinded zone key provides
resolvers
with the ability to verify the integrity of the published information
@@ -313,44 +324,44 @@
It can be represented by a Zone Top-Level Domain (zTLD) string.
</t>
<t>
- The zone type ztype is the unique zone type of the zone as registered
+ Each zone type (ztype) is assigned a unique 32-bit number when it is registered
in the GNUnet Assigned Numbers Authority <xref target="GANA" />.
- The zone type determines which cryptosystem is used for the
+ The ztype determines which cryptosystem is used for the
asymmetric and symmetric key operations of the zone.
- The zone type is identified by a 32-bit number.
- It always corresponds to a resource record type number identifying a
- delegation into a zone of this type.
+ The ztype number always corresponds to a resource record type
+ number identifying a delegation into a zone of this type. To
+ ensure that there are no conflicts with DNS record types, ztypes
+ are always assigned numeric values above 65535.
</t>
<t>
- For any zone, d is the private key. zk is the zone key.
- The specific formats depends on the zone type.
- The creation of zone keys for the default zone types are specified in
+ For any zone, let d be the private key and zk the public zone key.
+ The specific wire format used depends on the ztype.
+ The creation of zone keys for the default ztypes are specified in
<xref target="gnsrecords_delegation"/>.
- New zone types may be specified in the future, for example if the
+ New ztypes may be specified in the future, for example if the
cryptographic mechanisms used in this document are broken.
- Any zone type MUST define the following set of cryptographic functions:
+ Any ztype MUST define the following set of cryptographic functions:
</t>
<dl>
- <dt>Private-KeyGen() -> d</dt>
+ <dt>KeyGen() -> d, zk</dt>
<dd>
- is a function to generate a fresh private key d.
- </dd>
- <dt>Public-KeyGen(d) -> zk</dt>
- <dd>
- is a function to derive a zone key zk from a private key d.
+ is a function to generate a fresh private key d and
+ the corresponding public zone key zk.
</dd>
<dt>ZKDF-Private(d,label) -> d'</dt>
<dd>
is a zone key derivation function which blinds a private key d
using label, resulting in another private key which
- can be used to create cryptographic signatures.
+ can be used to create cryptographic signatures. We note that
+ GNS only requires a signature to be created directly with
+ d to sign a revocation message for the zone key zk.
</dd>
<dt>ZKDF-Public(zk,label) -> zk'</dt>
<dd>
is a zone key derivation function which blinds a zone key zk
using a label. zk and zk' must be unlinkable. Furthermore,
blinding zk with different values for the label must result
- in unlinkable different resulting values for zk'.
+ in unlinkable zk' values.
</dd>
<dt>S-Encrypt(zk,label,nonce,expiration,message) -> ciphertext</dt>
<dd>
@@ -367,17 +378,18 @@
data based on key material derived from the zone key,
a label, a nonce and an expiration.
</dd>
- <dt>Sign(d',message) -> signature</dt>
+ <dt>Sign(d,message) -> signature, Sign(d',message) -> signature</dt>
<dd>
- is a function to sign encrypted record data using the (blinded) private
- key d', yielding an unforgable cryptographic signature.
+ is a function to sign a message (typically encrypted record data) using the (blinded) private
+ key d (d'), yielding an unforgable cryptographic signature.
</dd>
- <dt>Verify(zk',message,signature) -> valid</dt>
+ <dt>Verify(zk,message,signature) -> boolean, Verify(zk',message,signature) -> boolean</dt>
<dd>
is a function to verify the signature was created by
- the private key d' derived from d and a label if
- zk' was derived from the corresponding zone key
- zk := Public-Keygen(d) and same label.
+ the private key d (or derived key d') corresponding to
+ the zone key zk (or derived zone key zk')
+ where d,zk := Keygen(). If deriviations were used, they
+ must have used the same label.
The function returns a boolean value of "TRUE" if the signature is valid,
and otherwise "FALSE".
</dd>
@@ -902,15 +914,11 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
<dl>
<dt>d</dt>
<dd>
- is a 256-bit ECDSA private key. The generation of the private
- scalar as defined in Section 2.2. of <xref target="RFC6979" /> represents the Private-KeyGen() function.
+ is a 256-bit ECDSA private key.
</dd>
<dt>zk</dt>
<dd>
- is the ECDSA zone key corresponding to d. Its generation is
- defined in Section 2.2. of <xref target="RFC6979" /> as the curve point d*G where G
- is the group generator of the elliptic curve.
- This generation represents the Public-KeyGen(d) function.
+ is the ECDSA public zone key corresponding to d.
</dd>
<dt>p</dt>
<dd>
@@ -926,6 +934,12 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
<dd>
is the order of the prime-order subgroup of edwards25519 in <xref target="RFC7748" />.
</dd>
+ <dt>KeyGen()</dt>
+ <dd>The generation of the private
+ scalar d and the curve point zk := d*G (where G is the group generator
+ of the elliptic curve) as defined in Section 2.2. of
+ <xref target="RFC6979" /> represents the KeyGen() function.
+ </dd>
</dl>
<t>
The zone type and zone key of a PKEY are 32 + 4 bytes in length. This means that
@@ -1065,9 +1079,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
<dl>
<dt>d</dt>
<dd>
- is a 256-bit EdDSA private key. The generation as defined
- in Section 3.2. of <xref target="RFC8032" /> and represents the Private-KeyGen()
- function.
+ is a 256-bit EdDSA private key.
</dd>
<dt>a</dt>
<dd>
@@ -1076,12 +1088,10 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
</dd>
<dt>zk</dt>
<dd>
- is the EdDSA public key corresponding to d. It is defined in
- Section 3.2 of <xref target="RFC8032" /> as the curve point a*G where G is the
- group generator of the elliptic curve and a is an integer
- derived from d using the SHA-512 hash function.
- This generation including the derivation of a represents the
- Public-KeyGen(d) function.
+ is the EdDSA public key corresponding to d. It is defined
+ as the curve point a*G where G is the
+ group generator of the elliptic curve
+ as defined in <xref target="ed25519" />.
</dd>
<dt>p</dt>
<dd>
@@ -1097,6 +1107,16 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
<dd>
is the order of the prime-order subgroup of edwards25519 in <xref target="RFC7748" />.
</dd>
+ <dt>KeyGen()</dt>
+ <dd>
+ The generation of the private key d and the associated public
+ key zk := a*G where G is the
+ group generator of the elliptic curve and a is an integer
+ derived from d using the SHA-512 hash function
+ as defined
+ in Section 3.2. of <xref target="RFC8032" /> represents the KeyGen()
+ function.
+ </dd>
</dl>
<t>
The zone type and zone key of an EDKEY are 32 + 4 bytes in length. This means that
