< draft-schanzen-gns-14.txt   draft-schanzen-gns-15.txt >
Independent Stream M. Schanzenbach Independent Stream M. Schanzenbach
Internet-Draft Fraunhofer AISEC Internet-Draft Fraunhofer AISEC
Intended status: Informational C. Grothoff Intended status: Informational C. Grothoff
Expires: 6 November 2022 Berner Fachhochschule Expires: 8 November 2022 Berner Fachhochschule
B. Fix B. Fix
GNUnet e.V. GNUnet e.V.
5 May 2022 7 May 2022
The GNU Name System The GNU Name System
draft-schanzen-gns-14 draft-schanzen-gns-15
Abstract Abstract
This document contains the GNU Name System (GNS) technical This document contains the GNU Name System (GNS) technical
specification. GNS is a decentralized and censorship-resistant name specification. GNS is a decentralized and censorship-resistant name
system that provides a privacy-enhancing alternative to the Domain system that provides a privacy-enhancing alternative to the Domain
Name System (DNS). Name System (DNS).
This document defines the normative wire format of resource records, This document defines the normative wire format of resource records,
resolution processes, cryptographic routines and security resolution processes, cryptographic routines and security
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 6 November 2022. This Internet-Draft will expire on 8 November 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 5, line 42 skipping to change at page 5, line 42
Name A name in GNS is a domain name as defined in [RFC8499] as an Name A name in GNS is a domain name as defined in [RFC8499] as an
ordered list of labels. Names are UTF-8 [RFC3629] strings ordered list of labels. Names are UTF-8 [RFC3629] strings
consisting of the list of labels concatenated with a label consisting of the list of labels concatenated with a label
separator. Names are resolved starting from the rightmost label. separator. Names are resolved starting from the rightmost label.
GNS does not impose length restrictions on names or labels. GNS does not impose length restrictions on names or labels.
However, applications MAY ensure that name and label lengths are However, applications MAY ensure that name and label lengths are
compatible with DNS and in particular IDNA [RFC5890]. In the compatible with DNS and in particular IDNA [RFC5890]. In the
spirit of [RFC5895], applications MAY preprocess names and labels spirit of [RFC5895], applications MAY preprocess names and labels
to ensure compatibility with DNS or support specific user to ensure compatibility with DNS or support specific user
expectations, for example according to [Unicode-UTS46]. expectations, for example according to [Unicode-UTS46]. A GNS
name may be indistinguishable from a DNS name and care must be
taken by applications and implementors when handling GNS names
(see Section 9.9).
Resolver The component of a GNS implementation which provides the Resolver The component of a GNS implementation which provides the
recursive name resolution logic defined in Section 7. recursive name resolution logic defined in Section 7.
Resource Record A GNS resource record is the information associated Resource Record A GNS resource record is the information associated
with a label in a GNS zone. A GNS resource record contains with a label in a GNS zone. A GNS resource record contains
information as defined by its resource record type. information as defined by its resource record type.
Start Zone In order to resolve any given GNS name an initial start Start Zone In order to resolve any given GNS name an initial start
zone must be determined for this name. The start zone can be zone must be determined for this name. The start zone can be
skipping to change at page 10, line 22 skipping to change at page 10, line 22
material derived from the zone key, a label, and an expiration material derived from the zone key, a label, and an expiration
timestamp. In order to leverage performance-enhancing caching timestamp. In order to leverage performance-enhancing caching
features of certain underlying storages, in particular DHTs, a features of certain underlying storages, in particular DHTs, a
deterministic encryption scheme is recommended. deterministic encryption scheme is recommended.
S-Decrypt(zk,label,expiration,ciphertext) -> message is a symmetric S-Decrypt(zk,label,expiration,ciphertext) -> message is a symmetric
decryption function which decrypts the encrypted record data based decryption function which decrypts the encrypted record data based
on key material derived from the zone key, a label, and an on key material derived from the zone key, a label, and an
expiration timestamp. expiration timestamp.
Sign(d,message) -> signature is a function to sign a message Sign(d,message) -> signature is a function to sign a message using
(typically encrypted record data) using the private key d, the private key d, yielding an unforgeable cryptographic
yielding an unforgeable cryptographic signature. In order to signature. In order to leverage performance-enhancing caching
leverage performance-enhancing caching features of certain features of certain underlying storages, in particular DHTs, a
underlying storages, in particular DHTs, a deterministic signature deterministic signature scheme is recommended.
scheme is recommended.
Verify(zk,message,signature) -> boolean is a function to verify the Verify(zk,message,signature) -> boolean is a function to verify the
signature was created using the private key d corresponding to the signature was created using the private key d corresponding to the
zone key zk where d,zk := Keygen(). The function returns a zone key zk where d,zk := Keygen(). The function returns a
boolean value of "TRUE" if the signature is valid, and otherwise boolean value of "TRUE" if the signature is valid, and otherwise
"FALSE". "FALSE".
SignDerived(d,label,message) -> signature is a function to sign a SignDerived(d,label,message) -> signature is a function to sign a
message (typically encrypted record data) that can be verified message (typically encrypted record data) that can be verified
using the derived zone key zk' := ZKDF(zk,label). In order to using the derived zone key zk' := ZKDF(zk,label). In order to
skipping to change at page 13, line 49 skipping to change at page 13, line 49
The resulting proofs are ready for dissemination. The concrete The resulting proofs are ready for dissemination. The concrete
dissemination and publication methods are out of scope of this dissemination and publication methods are out of scope of this
document. Given an average difficulty of D, the proofs have an document. Given an average difficulty of D, the proofs have an
expiration time of EPOCH. With each additional bit difficulty, the expiration time of EPOCH. With each additional bit difficulty, the
lifetime of the proof is prolonged for another EPOCH. Consequently, lifetime of the proof is prolonged for another EPOCH. Consequently,
by calculating a more difficult PoW, the lifetime of the proof can be by calculating a more difficult PoW, the lifetime of the proof can be
increased on demand by the zone owner. increased on demand by the zone owner.
The parameters are defined as follows: The parameters are defined as follows:
Z The number of PoWs required is fixed at 32. Z The number of PoWs that are required. Its value is fixed at 32.
D The minimum average difficulty is fixed at 22. D The minimum average difficulty. Its value is fixed at 22.
EPOCH A single epoch is fixed at 365 days. EPOCH A single epoch. Its value is fixed at 365 days in
microseconds.
The revocation message wire format is illustrated in Figure 5. The revocation message wire format is illustrated in Figure 5.
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| TIMESTAMP | | TIMESTAMP |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| TTL | | TTL |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| POW_0 | | POW_0 |
skipping to change at page 14, line 40 skipping to change at page 14, line 41
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 5: The Revocation Message Wire Format. Figure 5: The Revocation Message Wire Format.
TIMESTAMP denotes the absolute 64-bit date when the revocation was TIMESTAMP denotes the absolute 64-bit date when the revocation was
computed. In microseconds since midnight (0 hour), January 1, computed. In microseconds since midnight (0 hour), January 1,
1970 UTC in network byte order. This is the same value as the 1970 UTC in network byte order. This is the same value as the
time stamp used in the individual PoW calculations. time stamp used in the individual PoW calculations.
TTL denotes the relative 64-bit time to live of the record in TTL denotes the relative 64-bit time to live of the record in
microseconds also in network byte order. The field SHOULD be set microseconds in network byte order. The field SHOULD be set to
to EPOCH * 1.1. Given an average number of leading zeros D', then EPOCH * 1.1. Given an average number of leading zeros D', then
the field value MAY be increased up to (D'-D) * EPOCH * 1.1. the field value MAY be increased up to (D'-D) * EPOCH * 1.1.
Validators MAY reject messages with lower or higher values when Validators MAY reject messages with lower or higher values when
received. The EPOCH is extended by 10% in order to deal with received. The EPOCH is extended by 10% in order to deal with
unsynchronized clocks. unsynchronized clocks.
POW_i The values calculated as part of the PoW, in network byte POW_i The values calculated as part of the PoW, in network byte
order. Each POW_i MUST be unique in the set of POW values. To order. Each POW_i MUST be unique in the set of POW values. To
facilitate fast verification of uniqueness, the POW values must be facilitate fast verification of uniqueness, the POW values must be
given in strictly monotonically increasing order in the message. given in strictly monotonically increasing order in the message.
 End of changes. 10 change blocks. 
16 lines changed or deleted 19 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/