From dd85c56e1a0458c395823dde89cd52fafc3aacf9 Mon Sep 17 00:00:00 2001 From: Martin Schanzenbach Date: Wed, 22 Dec 2021 16:24:54 +0100 Subject: update --- draft-schanzen-gns.xml | 92 ++++++++++++++++++++++++++------------------------ 1 file changed, 48 insertions(+), 44 deletions(-) diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml index dff4ed7..7f14e6d 100644 --- a/draft-schanzen-gns.xml +++ b/draft-schanzen-gns.xml @@ -167,22 +167,51 @@ In GNS, any user may create and manage one or more cryptographically secured zones (). + A GNS 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 public and private zone keys using record label values. + Specifically, the zone owner can derive private keys for each record + set published under a label, and a + resolver can derive the corresponding public keys. + Without knowledge of the label values and the zone public keys, the + different derivations are unlinkable both to the original key and to each + other. + This prevents zone enumeration and requires knowledge + of both the public zone key and the label to confirm affiliation with a + specific zone. At the same time, the blinded zone public key provides nodes + with the ability to verifiy the integrity of the published information + without disclosing the originating zone. + + A zone can be populated with mappings from labels to resource records by its owner (). - Names can be delegated to other zones using delegation records and in + Labels can be delegated to other zones using delegation records and in order to support (legacy) applications as well as facilitate the use of petnames, GNS defines auxiliary record types in addition to supporting traditional DNS records. - Resource records of zones are grouped by label, encrypted and signed - before beging published as RRBLOCK in a distributed key-value storage + + + Zone contents are encrypted and signed + before being published as RRBLOCKs in a distributed key-value storage (). In this process, unique zone identification is hidden from the network through the use of key blinding. + 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. + Specification of such a distributed or decentralized storage is out of + scope of this document but possible existing implementations include those + based on , or + . + + Starting from a configurable root zone, names are resolved following zone delegations which are iteratively queried from the storage (). - In this document, the "implementer" refers to the developer building + In the remainder of this document, the "implementer" refers to the developer building a GNS implementation including, for example, zone management tools and name resolution components. An "application" refers to a component which uses a GNS implementation @@ -192,34 +221,16 @@
Zones - A zone in GNS is defined by a zone type that identifies - a cryptosystem and a public/private key pair where d is the private - key and zk the corresponding public key. - The contents of a zone are cryptographically signed before - being published by its owner for resolution by other parties. - Records are grouped by their label, and encrypted using an encryption - key derived from the label and the zone public key (see ). - Instead of the zone private key d, a GNS zone MUST support the creation - of signatures using a blinded public/private key pair. - This blinding is commonly realized using a deterministic key - derivation scheme. - Such a scheme allows the deterministic derivation of keys from - the original public and private zone keys using record label values. - Specifically, the zone owner can derive private keys for each record - set published under a label, and a - resolver can derive the corresponding public keys. - Without knowledge of the label values and the zone public keys, the - different derivations are unlinkable both to the original key and to each - other. - This prevents zone enumeration and requires knowledge - of both the public zone key and the label to confirm affiliation with a - specific zone. At the same time, the blinded zone public key provides nodes - with the ability to verifiy the integrity of the published information - without disclosing the originating zone. + A zone in GNS is defined by its zone type and zone ID. + The zone type determines a set of cryptographic functions which + enables the creation of signatures for zone contents using a blinded + public/private key pairs and encryption of zone contents. + Further, each zone can be represented by a Zone Top-Level Domain (zTLD) + string. - Based on the above, the following variables are associated with a zone in - GNS and used in the following throughout this specification. + In this section, the zone type, zone ID, zTLD and zone revocation is + defined.
Zone Type @@ -1397,30 +1408,23 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8) Any API which allows storing a value under a key and retrieving a value from the key can be used by an implementation for record storage. - 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. - Specification of such a distributed or decentralized storage is out of - scope of this document but possible existing implementations include , - , or . - - We assume that an implementation realizes two procedures on top of a storage: value ]]> - In GNS, resource records are grouped by their respective labels, + Resource records are grouped by their respective labels, encrypted and published together in a single resource records block (RRBLOCK) in the storage under a key q: PUT(q, RRBLOCK). The key q is derived from the zone key and the respective label of the contained records. The storage key derivation and records block creation is specified in the following sections. - A client implementation must enable the user the manage zones and use the - PUT storage procedure in order to update the zone contents. + A client implementation MUST enable the user the manage zones. + The implementation MUST use the PUT storage procedure in order to update + the zone contents accordingly.
The Storage Key @@ -2696,7 +2700,7 @@ cae1789d - + -- cgit v1.2.3