[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: fixup gts a bit
|
From: |
gnunet |
|
Subject: |
[lsd0001] branch master updated: fixup gts a bit |
|
Date: |
Wed, 22 Dec 2021 12:14:11 +0100 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a commit to branch master
in repository lsd0001.
The following commit(s) were added to refs/heads/master by this push:
new f855eb4 fixup gts a bit
f855eb4 is described below
commit f855eb42d287e0a5fe4021c1dd63680150bc24e5
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Wed Dec 22 12:14:07 2021 +0100
fixup gts a bit
---
draft-schanzen-gns.xml | 261 ++++++++++++++++++++++++-------------------------
1 file changed, 126 insertions(+), 135 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 49851ab..0b3f691 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -164,9 +164,9 @@
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 <xref
target="records_block"/>).
- Instead of the zone private key d, the signature MUST
- be created using a blinded public/private key pair.
- This blinding is realized using a deterministic key
+ 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.
@@ -183,45 +183,88 @@
without disclosing the originating zone.
</t>
<t>
- Based on the above, the following variables are associated with a zone
in GNS:
+ Based on the above, the following variables are associated with a zone
in
+ GNS and used in the following throughout this specification.
</t>
+ <section anchor="ztype" numbered="true" toc="default">
+ <name>Zone Type</name>
+ <t>
+ The Zone Type ztype is the unique zone type of the zone as registered
+ in the GNUnet Assigned Numbers Authority <xref target="GANA" />.
+ The Zone Type 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.
+ </t>
+ <t>
+ For any zone, d is the private zone key. zk is the public zone key.
+ The specific formats depends on the Zone Type.
+ The default zone delegation record types are specified in
+ <xref target="rrecords"/>.
+ New Zone Types 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:
+ </t>
<dl>
- <dt>ztype</dt>
+ <dt>Private-KeyGen() -> d</dt>
<dd>
- is the unique zone type of the zone as registered in the
- GNUnet Assigned Numbers Authority <xref target="GANA" />.
- The zone type determines which cryptosystem is used for the
- asymmetric and symmetric key operations of the zone. A 32-bit number.
+ is a function to generate a fresh private zone key d.
</dd>
- <dt>d</dt>
+ <dt>Public-KeyGen(d) -> zk</dt>
<dd>
- is the private zone key. The specific format depends on the zone type.
+ is a function to derive a public zone key zk from a private key d.
</dd>
- <dt>zk</dt>
+ <dt>ZKDF-Private(d,label) -> d'</dt>
<dd>
- is the public zone key. The specific format depends on the zone type.
+ is a zone key derivation function which blinds a private zone key d
+ using label, resulting in another private key which
+ can be used to create cryptographic signatures.
</dd>
- <dt>zid</dt>
+ <dt>ZKDF-Public(zk,label) -> zk'</dt>
<dd>
- is the zone identifier, a unique public identifier of a zone.
- It consists of the ztype and the public zone key zk.
+ is a zone key derivation function which blinds a public 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'.
</dd>
- <dt>zkl</dt>
+ <dt>S-Encrypt(zk,label,nonce,expiration,rdata) -> bdata</dt>
<dd>
- is the zone key label. It is a string representation of the zone
identifier.
+ is a deterministic symmetric encryption function which encrypts the
record
+ data rdata based on key material derived from the public zone key,
+ a label, a nonce and an expiration.
+ In order to leverage performance-enhancing caching features of certain
+ underlying storages, in particular DHTs, a deterministic encryption
+ scheme is recommended.
</dd>
- <dt>zTLD</dt>
+ <dt>S-Decrypt(zk,label,nonce,expiration,bdata) -> rdata</dt>
<dd>
- is the Zone Top-Level Domain. It is a string which encodes the zone
key
- label into a domain name.
- The zTLD is used as a globally unique reference to a specific
- namespace in the process of name resolution.
+ is a symmetric encryption function which decrypts the encrypted record
+ data bdata based on key material derived from the public zone key,
+ a label, a nonce an expiration.
+ </dd>
+ <dt>Sign(d',bdata) -> sig</dt>
+ <dd>
+ is a function to sign bdata using the (blinded) private key
+ d', yielding an unforgable cryptographic signature.
+ </dd>
+ <dt>Verify(zk',bdata,sig) -> valid</dt>
+ <dd>
+ is a function to verify the signature sig was created by
+ the a 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 function returns a boolean value of "TRUE" if the signature is
valid,
+ and otherwise "FALSE".
</dd>
</dl>
+ </section>
<section anchor="zid" numbered="true" toc="default">
<name>Zone ID</name>
- <t>
- The Zone ID wire format is illustrated in <xref target="figure_zid"/>.
+
+ <t>The Zone ID zid is a unique public identifier of a zone.
+ It consists of the ztype and the public zone key zk.
+ The wire format is illustrated in <xref target="figure_zid"/>.
</t>
<figure anchor="figure_zid">
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -233,18 +276,27 @@
/ /
]]></artwork>
</figure>
- <t>
- The zone key label is derived from the zone identifier using the
Crockford Base32
- encoding <xref target="CrockfordB32"/> but the letter "U" is decoded to
- the same Base32 value as the letter "V" in order to further increase
- tolerance for failures in character recognition.
- The encoding and decoding symbols for Crockford Base32 including this
modification are defined in
- <xref target="CrockfordB32Encode"/>.
- The functions for encoding and decoding based on this table are called
- GNSCrockfordEncode and GNSCrockfordDecode, respectively.
- </t>
- <figure anchor="CrockfordB32Encode">
- <artwork name="" type="" align="left" alt=""><![CDATA[
+ </section>
+ <section anchor="zTLD" numbered="true" toc="default">
+ <name>Zone Top-Level Domain</name>
+
+ <t>
+ The zTLD is the Zone Top-Level Domain.
+ It is a string which encodes the zone key into a domain name.
+ The zTLD is used as a globally unique reference to a specific
+ namespace in the process of name resolution.
+ To encode the zone key, a zone key label zkl is derived from the Zone
+ ID using the Crockford Base32
+ encoding <xref target="CrockfordB32"/> but the letter "U" is decoded
to
+ the same Base32 value as the letter "V" in order to further increase
+ tolerance for failures in character recognition.
+ The encoding and decoding symbols for Crockford Base32 including this
modification are defined in
+ <xref target="CrockfordB32Encode"/>.
+ The functions for encoding and decoding based on this table are called
+ GNSCrockfordEncode and GNSCrockfordDecode, respectively.
+ </t>
+ <figure anchor="CrockfordB32Encode">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
Symbol Decode Encode
Value Symbol Symbol
0 0 O o 0
@@ -280,95 +332,33 @@ Value Symbol Symbol
30 Y y Y
31 Z z Z
]]></artwork>
- </figure>
- <t>
- The Base32-Crockford Alphabet Including the Additional U Encode Symbol.
- </t>
- <t>
- For the string representation of a zone identifier we define:
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
+ </figure>
+ <t>
+ The Base32-Crockford Alphabet Including the Additional U Encode
Symbol.
+ </t>
+ <t>
+ For the string representation of a zone identifier we define:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
zkl := GNSCrockfordEncode(zid)
zid := GNSCrockfordDecode(zkl)
]]></artwork>
- <t>
- If zkl is less than 63 characters, it can directly be
- used as a zTLD.
- If zkl is be longer than 63 characters, the
- zTLD is constructed by dividing zkl into smaller labels separated by the
- label separator ".".
- Here, the most significant bytes of the "zid" must be contained
- in the rightmost label of the resulting string and the least significant
- bytes in the leftmost label of the resulting string. This allows the
- resolver to determine the zone type and zkl length from the rightmost
label.
- For example, assuming a zkl of 130 characters, the encoding would be:
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
+ <t>
+ If zkl is less than 63 characters, it can directly be
+ used as a zTLD.
+ If zkl is be longer than 63 characters, the
+ zTLD is constructed by dividing zkl into smaller labels separated by
the
+ label separator ".".
+ Here, the most significant bytes of the "zid" must be contained
+ in the rightmost label of the resulting string and the least
significant
+ bytes in the leftmost label of the resulting string. This allows the
+ resolver to determine the zone type and zkl length from the rightmost
label.
+ For example, assuming a zkl of 130 characters, the encoding would be:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
]]></artwork>
- </section>
- <section anchor="zone_types" numbered="true" toc="default">
- <name>Zone Type</name>
- <t>
- The zone type is identified by a 32-bit number. The zone type number
- always corresponds to a resource record type number identifying a
- delegation into a zone of this type.
- Resource record types are discussed in the Section <xref
target="rrecords"/>.
- A zone type defines a family of eight functions:
- </t>
- <dl>
- <dt>Private-KeyGen() -> d</dt>
- <dd>
- is a function to generate a fresh private zone key d.
- </dd>
- <dt>Public-KeyGen(d) -> zk</dt>
- <dd>
- is a function to derive a public zone key zk from a private key d.
- </dd>
- <dt>ZKDF-Private(d,label) -> d'</dt>
- <dd>
- is a zone key derivation function which blinds a private zone key d
- using label, resulting in another private key which
- can be used to create cryptographic signatures.
- </dd>
- <dt>ZKDF-Public(zk,label) -> zk'</dt>
- <dd>
- is a zone key derivation function which blinds a public 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'.
- </dd>
- <dt>S-Encrypt(zk,label,nonce,expiration,rdata) -> bdata</dt>
- <dd>
- is a deterministic symmetric encryption function which encrypts the
record
- data rdata based on key material derived from the public zone key,
- a label, a nonce and an expiration.
- In order to leverage performance-enhancing caching features of certain
- underlying storages, in particular DHTs, a deterministic encryption
- scheme is recommended.
- </dd>
- <dt>S-Decrypt(zk,label,nonce,expiration,bdata) -> rdata</dt>
- <dd>
- is a symmetric encryption function which decrypts the encrypted record
- data bdata based on key material derived from the public zone key,
- a label, a nonce an expiration.
- </dd>
- <dt>Sign(d',bdata) -> sig</dt>
- <dd>
- is a function to sign bdata using the (blinded) private key
- d', yielding an unforgable cryptographic signature.
- </dd>
- <dt>Verify(zk',bdata,sig) -> valid</dt>
- <dd>
- is a function to verify the signature sig was created by
- the a 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 function returns a boolean value of "TRUE" if the signature is
valid,
- and otherwise "FALSE".
- </dd>
- </dl>
- </section>
+ </section>
</section>
<section anchor="rrecords" numbered="true" toc="default">
<name>Resource Records</name>
@@ -973,8 +963,8 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
Nickname records can be used by zone administrators to publish an
the label that a zone prefers to have used when it is referred to.
This is a suggestion to other zones what label to use when creating a
- delegation record (<xref target="zone_types" />) containing this
zone's
- public zone key.
+ delegation record (<xref target="gnsrecords_delegation" />) containing
+ this zone's public zone key.
This record SHOULD only be stored under the empty label "@" but MAY be
returned with record sets under any label as a supplemental record.
<xref target="nick_processing"/> details how a resolver must process
@@ -1056,12 +1046,13 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
<section anchor="gnsrecords_vpn" numbered="true" toc="default">
<name>GTS</name>
<t>
- The GNUnet Tunnel Record <xref target="GNUnet"/> can
- establish a tunnel between two peers in the peer-to-peer network.
+ The GNUnet Tunnel Service record is used by
+ applications to establish a tunnel between two peers in the
+ peer-to-peer network (see <xref target="GNUnet"/>).
In order to facilitate the use of such tunnels, the
- GTS record allows resolvers to automatically initiate its
establishment
- and provide IP address information in the resolution process as
- specified in <xref target="resolution"/>.
+ The GTS record serves as an example to how resolvers may automatically
+ initiate tunnel establishment and provide IP address information in
the
+ resolution process as specified in <xref target="resolution"/>.
</t>
<t>
A GTS DATA entry wire format is illustrated in
@@ -1093,7 +1084,8 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
</dd>
<dt>PROTO</dt>
<dd>
- the 16-bit protocol number, e.g. 6 for TCP. In network byte order.
+ the 16-bit tunnel protocol number. In network byte order.
+ The possible values are defined by the GNUnet Tunnel Service.
</dd>
<dt>SERVICE NAME</dt>
<dd>
@@ -1216,7 +1208,7 @@ q := SHA512 (HDKD-Public(zk, label))
the PUBLIC KEY field.
The signature is created using the Sign() function of
the cryptosystem of the zone and the derived private key
- "ZKDF-Private(d, label)" (see <xref target="zone_types" />).
+ "ZKDF-Private(d, label)" (see <xref target="ztype" />).
</dd>
<dt>SIZE</dt>
<dd>
@@ -1505,7 +1497,7 @@ q := SHA512 (HDKD-Public(zk, label))
which is revoked and corresponds to the key used in the PoW.
The signature is created using the Sign() function of
the cryptosystem of the zone and the private zone key
- (see <xref target="zone_types" />).
+ (see <xref target="ztype" />).
</dd>
</dl>
<t>
@@ -1585,7 +1577,7 @@ q := SHA512 (HDKD-Public(zk, label))
provided by the client.
The GNS resolver will use the desired record type to guide
processing, for example by providing conversion of GTS records to A
- or AAAA records, if that is desired.
+ or AAAA records.
However, filtering of record sets according to the required record
types MUST still be done by the client after the resource record set
@@ -1863,12 +1855,11 @@ example.com = zk2
<section anchor="vpn_processing" numbered="true" toc="default">
<name>GTS</name>
<t>
- At the end of the recursion,
+ At the end of the recursion,
if the queried record type is either A or AAAA and the retrieved
record set contains at least one GTS record, the resolver SHOULD
open a tunnel and return the IPv4 or IPv6 tunnel address,
respectively.
- The type of tunnel depends on the contents of the GTS record data.
If the implementation does not have the capacity to establish
a GTS tunnel, for example because it is not connected to the
GNUnet
network, the record set MUST be returned as retrieved from the
network.
@@ -2148,7 +2139,7 @@ Number | Name | Contact | References | Description
65536 | PKEY | N/A | [This.I-D] | GNS zone delegation (PKEY)
65537 | NICK | N/A | [This.I-D] | GNS zone nickname
65538 | LEHO | N/A | [This.I-D] | GNS legacy hostname
-65539 | GTS | N/A | [This.I-D] | GTS resolution
+65539 | GTS | N/A | [This.I-D] | GTS tunnel metadata
65540 | GNS2DNS | N/A | [This.I-D] | Delegation to DNS
65556 | EDKEY | N/A | [This.I-D] | GNS zone delegation (EDKEY)
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: fixup gts a bit,
gnunet <=