[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: try to fix signatures
From: |
gnunet |
Subject: |
[lsd0001] branch master updated: try to fix signatures |
Date: |
Tue, 08 Feb 2022 20:21:29 +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 a000871 try to fix signatures
a000871 is described below
commit a000871fddb6d29af43f532fde21fe743fd17251
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Tue Feb 8 20:21:23 2022 +0100
try to fix signatures
---
draft-schanzen-gns.xml | 115 ++++++++++++++++++++++++++-----------------------
1 file changed, 62 insertions(+), 53 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index df41a8e..2c54320 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -192,8 +192,10 @@
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. Labels MUST be canonicalized using
- Normalization Form C (NFC) <xref target="Unicode-UAX15"/>.
+ 63 bytes for compatibility with applications enforcing DNS legacy
+ limitations.
+ Labels MUST be canonicalized using
+ Normalization Form C (NFC) <xref target="Unicode-UAX15"/>.
</dd>
<dt>Apex Label</dt>
<dd>
@@ -201,7 +203,7 @@
quotes).
The apex label is used to publish resource
records in a zone that can be resolved without providing a specific
- name. It is the GNS method to provide what is the "zone apex" in DNS
+ label. It is the GNS method to provide what is the "zone apex" in DNS
<xref target="RFC4033"/>.
</dd>
<dt>Name</dt>
@@ -269,17 +271,10 @@
A GNS resource record contains information as defined by its
resource record type.
</dd>
- <dt>Client</dt>
- <dd>
- The client is an implementation component which facilitates
- zone management and name resolution.
- It enables the user to manage zones (<xref target="publish"/>) and
- resolve names (<xref target="resolution"/>).
- </dd>
<dt>Application</dt>
<dd>
An application refers to a component which uses a GNS implementation
- to resolve records from the network and (usually) processes its
contents.
+ to resolve names into records and processes its contents.
</dd>
</dl>
</section>
@@ -358,8 +353,7 @@
Each zone can be represented by a Zone Top-Level Domain (zTLD) string.
</t>
<t>
- <!-- FIXME: MUST or SHOULD? Was must reformulated SHOULD -->
- A client implementation SHOULD enable the user to create and manage
zones.
+ A implementation SHOULD enable the user to create and manage zones.
If this functionality is not implemented, names can still be resolved
if zone keys for the initial step in the name resolution are available
(see <xref target="resolution"/>).
@@ -419,7 +413,7 @@
data based on key material derived from the zone key,
a label, and an expiration timestamp.
</dd>
- <dt>Sign(d,message) -> signature, Sign(d',message) -> signature</dt>
+ <dt>Sign(d,message) -> signature, SignDerived(d,label,message) ->
signature</dt>
<dd>
is a function to sign a message (typically encrypted record data)
using the (blinded) private
key d (d'), yielding an unforgeable cryptographic signature.
@@ -427,7 +421,7 @@
underlying storages, in particular DHTs, a deterministic signature
scheme is recommended.
</dd>
- <dt>Verify(zk,message,signature) -> boolean,
Verify(zk',message,signature) -> boolean</dt>
+ <dt>Verify(zk,message,signature) -> boolean,
VerifyDerived(zk,label,message,signature) -> boolean</dt>
<dd>
is a function to verify the signature was created by
the private key d (or derived key d') corresponding to
@@ -1040,8 +1034,21 @@ ZKDF-Public(zk,label)
The Sign() and Verify() functions
for PKEY zones are implemented using 512-bit ECDSA deterministic
signatures as specified in <xref target="RFC6979" />.
- The same functions can be used for derived keys.
+ The same functions can be used for derived keys:
</t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+SignDerived(d,label,message):
+ d' := ZKDF-Private(d,label)
+ return Sign(d',message)
+ ]]></artwork>
+ <t>
+ A signature (R,S) is valid if the following holds:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+VerifyDerived(zk,label,message,signature):
+ zk' := ZKDF-Public(zk,label)
+ return Verify(zk',message,signature)
+ ]]></artwork>
<t>
The S-Encrypt() and S-Decrypt() functions use AES in counter mode
as defined in <xref target="MODES" /> (CTR-AES-256):
@@ -1191,22 +1198,24 @@ S-Decrypt(zk,label,expiration,ciphertext):
</t>
<t>
The "EDKEY" ZKDF instantiation is based on <xref target="Tor224"/>.
- For brevity, instead of using d as a parameter to the derivation,
- we define the ZKDF-Private() procedure on the derived integer a.
The calculation of a is defined in Section 5.1.5 of <xref
target="RFC8032" />.
Given a label, the output of the ZKDF-Private function for zone
key blinding is calculated as follows for EDKEY zones:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
-ZKDF-Private(a,label):
+ZKDF-Private(d,label):
+ a := SHA-512 (d)
+ a[0] &= 248;
+ a[31] &= 127;
+ a[31] |= 64;
zk := a * G
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
h[31] &= 7
a1 := a >> 3
a2 := (h * a1) mod L
- a' = a2 << 3
- return a'
+ d' := a2 << 3
+ return d'
]]></artwork>
<t>
Equally, given a label, the output of the ZKDF-Public function is
@@ -1216,7 +1225,7 @@ ZKDF-Private(a,label):
ZKDF-Public(zk,label):
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
- h[31] &= 7 // Implies h mod L == h
+ h[31] &= 7
zk' := h * zk
return zk'
]]></artwork>
@@ -1256,9 +1265,9 @@ ZKDF-Public(zk,label):
be implemented as defined in <xref target="RFC8032" />.
</t>
<t>
- Signatures for EDKEY zones using the derived private key a'
+ Signatures for EDKEY zones using the derived private scalar d'
are not compliant with <xref target="RFC8032" />.
- As the corresponding private key to the derived private scalar a'
+ As the corresponding private key to the derived private scalar d'
is not known, it is not possible to deterministically derive the
signature part R according to <xref target="RFC8032" />.
Instead, signatures MUST be generated as follows for any given
@@ -1270,24 +1279,22 @@ ZKDF-Public(zk,label):
of the R value of the signature, ensuring that it is never reused
for two different derivation paths or messages.
</t>
- <!-- Blinded key signatures need a different method signature
- FIXME Should we use a'
- nonce := SHA-256 (a')? Changed for now. Unclear if ok.
- -->
<artwork name="" type="" align="left" alt=""><![CDATA[
-Sign(d,message):
+SignDerived(d,label,message):
+ d' := ZKDF-Private(d,label)
dh := SHA-512 (d)
nonce := SHA-256 (dh[32..63] | h)
r := SHA-512 (nonce | message)
R := r * G
- S := r + SHA-512(R | zk' | message) * a' mod L
+ S := r + SHA-512(R | zk' | message) * d' mod L
return (R,S)
]]></artwork>
<t>
A signature (R,S) is valid if the following holds:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
-Verify(zk',message,signature):
+VerifyDerived(zk,label,message,signature):
+ zk' := ZKDF-Public(zk,label)
(R,S) := signature
return S * G == R + SHA-512(R, zk', message) * zk'
]]></artwork>
@@ -1410,6 +1417,8 @@ S-Decrypt(zk,label,expiration,ciphertext):
in DNS followed by a DNS server. Both names are in the format defined
in
<xref target="RFC1034" /> for DNS names.
There MAY be multiple GNS2DNS records under a label.
+ There MAY also be DNSSEC DS records or any other records used to
+ secure the connection with the DNS servers under the same label.
No other record types are allowed in the same record set.
A GNS2DNS DATA entry is illustrated in <xref
target="figure_gns2dnsrecord"/>.</t>
<figure anchor="figure_gns2dnsrecord">
@@ -1592,7 +1601,8 @@ S-Decrypt(zk,label,expiration,ciphertext):
</dd>
<dt>SVC</dt>
<dd>
- the 16-bit service value of the boxed record, i.e. the port number.
+ the 16-bit service value of the boxed record. In case of
+ TCP and UDP it is the port number.
In network byte order.
</dd>
<dt>TYPE</dt>
@@ -1869,21 +1879,14 @@ q := SHA-512 (ZKDF-Public(zk, label))
<xref target="governance" />.
</t>
<t>
- <!-- FIXME removed client everywhere. We only have an implementation -->
- The client implementation MAY allow the user to provide a desired
- record type for the resolver.
+ The application MAY provide a desired record type to the resolver.
The desired record type is used to guide processing.
- For example, if zone delegation record type is requested, the
- resolution of the apex label in that zone may not be necessary, as
+ For example, if a zone delegation record type is requested, the
+ resolution of the apex label in that zone must be skipped, as
the desired record is already found.
- <!-- FIXME: Is this still necessary? Clarify the purpose of the
- provided record type and normatively define that resolver MUST NOT
- filter? THe normative statement for the CLIENT does not make sense.
- We need a normative statement for the implementer of GNS. -->
The resolver implementation MUST NOT filter results according to the
desired
record type.
- Filtering of record sets MAY still be done by the client which
- could be a stub resolver.
+ Filtering of record sets is typically done by the application.
</t>
<section anchor="governance" numbered="true" toc="default">
<name>Start Zones</name>
@@ -1892,7 +1895,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
or only the client? Because the resolver needs to know the zones for
redirects, for example -->
The resolution of a GNS name starts in an initial start zone.
- The local resolver may have one or more local start zones configured
+ The resolver may have one or more local start zones configured
which point to local or remote zone keys.
A resolver may also determine the start zone from the
suffix of the name given for resolution, or using information
@@ -1908,9 +1911,9 @@ q := SHA-512 (ZKDF-Public(zk, label))
management of root servers in DNS (see <xref target="RFC8324"/>,
Section 3.10 and 3.12).
</t>
<t>
- In the following, we give examples how a local client SHOULD
+ In the following, we give examples how a resolver SHOULD
discover the start zone. The process given is not exhaustive and
- clients MAY supplement it with other mechanisms or ignore it if the
+ resolvers MAY supplement it with other mechanisms or ignore it if the
particular application requires a different process.
</t>
<t>
@@ -2106,6 +2109,12 @@ example.com = zk2
identical for all of them, if not the resolution fails and an
appropriate error is SHOULD be returned to the application.
</t>
+ <t>
+ If there are DNSSEC DS records or any other records used to
+ secure the connection with the DNS servers stored under the label,
+ the DNS resolver SHOULD use them to secure the connection with
+ the DNS server.
+ </t>
<t>
Once the IP addresses of the DNS servers have been determined,
the DNS name from the GNS2DNS record is appended
@@ -2115,7 +2124,7 @@ example.com = zk2
support recursive DNS resolution and MUST NOT delegate this to the
authoritative DNS servers.
The first successful recursive name resolution result
- is returned to the client.
+ is returned to the application.
In addition, the resolver SHOULD return the queried DNS name as a
supplemental LEHO record (see <xref target="gnsrecords_leho" />)
with a
relative expiration time of one hour.
@@ -2139,7 +2148,7 @@ example.com = zk2
still be returned, even if DNS support is disabled by the
GNS resolver configuration.
</t>
- <!-- FIXME: Loop detection -->
+ <!-- FIXME: State the DNS resolution never "returns" to GNS. -->
</section>
<section anchor="box_processing" numbered="true" toc="default">
<name>BOX</name>
@@ -2176,7 +2185,7 @@ example.com = zk2
recursion is continued with the record value as authoritative zone
and the apex label "@" as remaining name.
Except in the case where the desired record type as specified by
- the client is equal to the ztype, in which case the delegation
+ the application is equal to the ztype, in which case the
delegation
record is returned.
</t>
</section>
@@ -2185,7 +2194,7 @@ example.com = zk2
<t>
NICK records are only relevant to the recursive resolver
if the record set in question is the final result which is to
- be returned to the client. The encountered NICK records may either
+ be returned to the application. The encountered NICK records may
either
be supplemental (see <xref target="rrecords"/>) or
non-supplemental.
If the NICK record is supplemental, the resolver only returns the
@@ -2196,7 +2205,7 @@ example.com = zk2
</t>
<t>
The differentiation between a supplemental and non-supplemental
- NICK record allows the client to match the record to the
+ NICK record allows the application to match the record to the
authoritative zone. Consider the following example:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -2207,7 +2216,7 @@ NICK: eve (non-Supplemental)
]]></artwork>
<t>
In this example, the returned NICK record is non-supplemental.
- For the client, this means that the NICK belongs to the zone
+ For the application, this means that the NICK belongs to the zone
"alice.example" and is published under the apex label along with an A
record. The NICK record should be interpreted as: The zone defined by
"alice.example" wants to be referred to as "eve".
@@ -2596,7 +2605,7 @@ Purpose | Name | References | Comment
is an active deployment of GNS on top of its <xref target="R5N"/>
DHT. The <xref target="GoGNS"/> implementation uses this deployment
by building on top of the GNUnet DHT services available on any
- GNUnet peer. It shows how GNS implementations and client resolvers
+ GNUnet peer. It shows how GNS implementations
can attach to this existing deployment and participate in name
resolution as well as zone publication.
</t>
--
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: try to fix signatures,
gnunet <=