commit cae202d6dd1fd5724581d76235a2d15f8ce179cb
parent 46f7a1a2604fcd7a42dd5ce64150c17146c42f88
Author: Schanzenbach, Martin <mschanzenbach@posteo.de>
Date: Fri, 4 Oct 2019 20:51:41 +0200
change wording
Diffstat:
3 files changed, 271 insertions(+), 270 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
@@ -1667,25 +1667,77 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-block-data-encryption-and-d" class="section-name selfRef">Block data encryption and decryption</a>
</h3>
<p id="section-4.3-1">
- A symmetric encryption scheme is used to en-/decrypt the "BDATA" field
- in a GNS record block. The keys are derived from the record label
- and the zone key "zk".
- Upon receiving a resource records block, first the validity of a given
- "zk_h" MUST be checked by computing "h" from "zk" and label and
- verifying that both are equal. This step is mandatory to prevent record
- spoofing.
- For decryption of the resource records block payload,
- the key material "K" and initialization vector "IV" for the
- symmetric en-/decryption are derived:<a href="#section-4.3-1" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-4.3-2">
+ A symmetric encryption scheme is used to encrypt the resource records
+ set RDATA into the BDATA field of a GNS record block.
+ The wire format of the RDATA looks as follows:<a href="#section-4.3-1" class="pilcrow">¶</a></p>
+<div id="figure_rdata">
+<figure id="figure-8">
+ <div class="artwork art-text alignLeft" id="section-4.3-2.1">
+<pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | RR COUNT | EXPIRA- /
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ / -TION | DATA SIZE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TYPE | FLAGS |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA SIZE | TYPE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | FLAGS | DATA /
+ +-----+-----+-----+-----+ /
+ / +-----------------------/
+ / | /
+ +-----------------------+ /
+ / PADDING /
+ / /
+ </pre>
+</div>
+<figcaption><a href="#figure-8" class="selfRef">Figure 8</a></figcaption></figure>
+</div>
+<p id="section-4.3-3">where:<a href="#section-4.3-3" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-4.3-4">
+ <dt id="section-4.3-4.1">RR COUNT</dt>
+ <dd id="section-4.3-4.2">
+ A 32-bit value containing the number of variable-length resource
+ records which are
+ following after this field in network byte order.
+ The resource record format is defined in <a href="#rrecords" class="xref">Section 3</a>.<a href="#section-4.3-4.2" class="pilcrow">¶</a>
+</dd>
+ <dt id="section-4.3-4.3">PADDING</dt>
+ <dd id="section-4.3-4.4">
+ The padding MUST contain the value 0 in all octets.
+ The padding MUST ensure that the size of the RDATA is a power of two.
+ As a special exception, record sets with (only) a PKEY record type
+ are never padded. Note that a record set with a PKEY record MUST NOT
+ contain other records.<a href="#section-4.3-4.4" class="pilcrow">¶</a>
+</dd>
+ </dl>
+<p id="section-4.3-5">
+ Upon receiving a resource records block, first the validity of a
+ given "zk_h" MUST be checked by computing the expected "zk_h" from "zk"
+ and label (as defined in <a href="#blinding" class="xref">Section 4.1</a>) and verifying that
+ both are equal. This step is mandatory to prevent record spoofing.<a href="#section-4.3-5" class="pilcrow">¶</a></p>
+<p id="section-4.3-6">
+ The symmetric keys and initialization vectors are derived from the
+ record label and the zone key "zk". For decryption of the resource
+ records block payload, the key material "K" and initialization vector
+ "IV" for the symmetric en-/decryption are derived as follows:<a href="#section-4.3-6" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-4.3-7">
<pre>
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
K := HKDF-Expand (PRK_k, label, 512 / 8);
IV := HKDF-Expand (PRK_iv, label, 256 / 8)
- </pre><a href="#section-4.3-2" class="pilcrow">¶</a>
+ </pre><a href="#section-4.3-7" class="pilcrow">¶</a>
</div>
-<p id="section-4.3-3">
+<p id="section-4.3-8">
HKDF is a hash-based key derivation function as defined in
<span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>. Specifically, HMAC-SHA512 is used for the
extraction phase and HMAC-SHA256 for the expansion phase.
@@ -1693,10 +1745,10 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
keys and 32 octets (256 bit) for the initialization vectors.
We divide the resulting keying material "K" into a 256-bit AES
<span>[<a href="#RFC3826" class="xref">RFC3826</a>]</span> key
- and a 256-bit TWOFISH <span>[<a href="#TWOFISH" class="xref">TWOFISH</a>]</span> key:<a href="#section-4.3-3" class="pilcrow">¶</a></p>
+ and a 256-bit TWOFISH <span>[<a href="#TWOFISH" class="xref">TWOFISH</a>]</span> key:<a href="#section-4.3-8" class="pilcrow">¶</a></p>
<div id="figure_hkdf_keys">
-<figure id="figure-8">
- <div class="artwork art-text alignLeft" id="section-4.3-4.1">
+<figure id="figure-9">
+ <div class="artwork art-text alignLeft" id="section-4.3-9.1">
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1712,14 +1764,14 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-8" class="selfRef">Figure 8</a></figcaption></figure>
+<figcaption><a href="#figure-9" class="selfRef">Figure 9</a></figcaption></figure>
</div>
-<p id="section-4.3-5">
+<p id="section-4.3-10">
Similarly, we divide "IV" into a 128-bit initialization vector
- and a 128-bit initialization vector:<a href="#section-4.3-5" class="pilcrow">¶</a></p>
+ and a 128-bit initialization vector:<a href="#section-4.3-10" class="pilcrow">¶</a></p>
<div id="figure_hkdf_ivs">
-<figure id="figure-9">
- <div class="artwork art-text alignLeft" id="section-4.3-6.1">
+<figure id="figure-10">
+ <div class="artwork art-text alignLeft" id="section-4.3-11.1">
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1731,70 +1783,18 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-9" class="selfRef">Figure 9</a></figcaption></figure>
+<figcaption><a href="#figure-10" class="selfRef">Figure 10</a></figcaption></figure>
</div>
-<p id="section-4.3-7">
+<p id="section-4.3-12">
The keys and IVs are used for a CFB128-AES-256 and
CFB128-TWOFISH-256 chained symmetric cipher. Both ciphers are used in
- Cipher FeedBack (CFB) mode <span>[<a href="#RFC3826" class="xref">RFC3826</a>]</span>.<a href="#section-4.3-7" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-4.3-8">
+ Cipher FeedBack (CFB) mode <span>[<a href="#RFC3826" class="xref">RFC3826</a>]</span>.<a href="#section-4.3-12" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-4.3-13">
<pre>
RDATA := AES(AES KEY, AES IV, TWOFISH(TWOFISH KEY, TWOFISH IV, BDATA))
BDATA := TWOFISH(TWOFISH KEY, TWOFISH IV, AES(AES KEY, AES IV, RDATA))
- </pre><a href="#section-4.3-8" class="pilcrow">¶</a>
-</div>
-<p id="section-4.3-9">
- The decrypted RDATA has the following format:<a href="#section-4.3-9" class="pilcrow">¶</a></p>
-<div id="figure_rdata">
-<figure id="figure-10">
- <div class="artwork art-text alignLeft" id="section-4.3-10.1">
-<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | RR COUNT | EXPIRA- /
- +-----+-----+-----+-----+-----+-----+-----+-----+
- / -TION | DATA SIZE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TYPE | FLAGS |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA /
- +-----+-----+-----+-----+ /
- / +-----------------------/
- / | /
- +-----------------------+ /
- / PADDING /
- / /
- </pre>
-</div>
-<figcaption><a href="#figure-10" class="selfRef">Figure 10</a></figcaption></figure>
+ </pre><a href="#section-4.3-13" class="pilcrow">¶</a>
</div>
-<p id="section-4.3-11">where:<a href="#section-4.3-11" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-4.3-12">
- <dt id="section-4.3-12.1">RR COUNT</dt>
- <dd id="section-4.3-12.2">
- A 32-bit value containing the number of variable-length resource
- records which are
- following after this field in network byte order.
- The resource record format is defined in <a href="#rrecords" class="xref">Section 3</a>.<a href="#section-4.3-12.2" class="pilcrow">¶</a>
-</dd>
- <dt id="section-4.3-12.3">PADDING</dt>
- <dd id="section-4.3-12.4">
- The padding MUST contain the value 0 in all octets.
- The padding MUST ensure that the size of the RDATA is a power of two.
-
- As a special exception, record sets with (only) a PKEY record type
- are never padded. Note that a record set with a PKEY record MUST NOT contain
- other records.<a href="#section-4.3-12.4" class="pilcrow">¶</a>
-</dd>
- </dl>
</section>
</section>
</div>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
@@ -72,13 +72,13 @@ Table of Contents
4.2. Resource records block . . . . . . . . . . . . . . . . . 9
4.3. Block data encryption and decryption . . . . . . . . . . 10
5. Internationalization and Character Encoding . . . . . . . . . 12
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
- 7. Record Resolution . . . . . . . . . . . . . . . . . . . . . . 13
- 8. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 13
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
+ 7. Record Resolution . . . . . . . . . . . . . . . . . . . . . . 12
+ 8. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 12
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 13
- 11. Normative References . . . . . . . . . . . . . . . . . . . . 16
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
+ 11. Normative References . . . . . . . . . . . . . . . . . . . . 15
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
@@ -525,42 +525,77 @@ Internet-Draft The GNU Name System July 2019
4.3. Block data encryption and decryption
- A symmetric encryption scheme is used to en-/decrypt the "BDATA"
- field in a GNS record block. The keys are derived from the record
- label and the zone key "zk". Upon receiving a resource records
- block, first the validity of a given "zk_h" MUST be checked by
- computing "h" from "zk" and label and verifying that both are equal.
- This step is mandatory to prevent record spoofing. For decryption of
- the resource records block payload, the key material "K" and
- initialization vector "IV" for the symmetric en-/decryption are
- derived:
+ A symmetric encryption scheme is used to encrypt the resource records
+ set RDATA into the BDATA field of a GNS record block. The wire
+ format of the RDATA looks as follows:
- PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
- PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
- K := HKDF-Expand (PRK_k, label, 512 / 8);
- IV := HKDF-Expand (PRK_iv, label, 256 / 8)
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | RR COUNT | EXPIRA- /
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ / -TION | DATA SIZE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TYPE | FLAGS |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA SIZE | TYPE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | FLAGS | DATA /
+ +-----+-----+-----+-----+ /
+ / +-----------------------/
+ / | /
+ +-----------------------+ /
+ / PADDING /
+ / /
- HKDF is a hash-based key derivation function as defined in [RFC5869].
- Specifically, HMAC-SHA512 is used for the extraction phase and HMAC-
- SHA256 for the expansion phase. The output keying material is 64
- octets (512 bit) for the symmetric keys and 32 octets (256 bit) for
- the initialization vectors. We divide the resulting keying material
- "K" into a 256-bit AES [RFC3826] key and a 256-bit TWOFISH [TWOFISH]
- key:
+ Figure 8
+Schanzenbach, et al. Expires 24 January 2020 [Page 10]
+
+Internet-Draft The GNU Name System July 2019
+ where:
+ RR COUNT A 32-bit value containing the number of variable-length
+ resource records which are following after this field in network
+ byte order. The resource record format is defined in Section 3.
+ PADDING The padding MUST contain the value 0 in all octets. The
+ padding MUST ensure that the size of the RDATA is a power of two.
+ As a special exception, record sets with (only) a PKEY record type
+ are never padded. Note that a record set with a PKEY record MUST
+ NOT contain other records.
+ Upon receiving a resource records block, first the validity of a
+ given "zk_h" MUST be checked by computing the expected "zk_h" from
+ "zk" and label (as defined in Section 4.1) and verifying that both
+ are equal. This step is mandatory to prevent record spoofing.
+ The symmetric keys and initialization vectors are derived from the
+ record label and the zone key "zk". For decryption of the resource
+ records block payload, the key material "K" and initialization vector
+ "IV" for the symmetric en-/decryption are derived as follows:
-Schanzenbach, et al. Expires 24 January 2020 [Page 10]
-
-Internet-Draft The GNU Name System July 2019
+ PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
+ PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
+ K := HKDF-Expand (PRK_k, label, 512 / 8);
+ IV := HKDF-Expand (PRK_iv, label, 256 / 8)
+ HKDF is a hash-based key derivation function as defined in [RFC5869].
+ Specifically, HMAC-SHA512 is used for the extraction phase and HMAC-
+ SHA256 for the expansion phase. The output keying material is 64
+ octets (512 bit) for the symmetric keys and 32 octets (256 bit) for
+ the initialization vectors. We divide the resulting keying material
+ "K" into a 256-bit AES [RFC3826] key and a 256-bit TWOFISH [TWOFISH]
+ key:
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -575,7 +610,15 @@ Internet-Draft The GNU Name System July 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 8
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 11]
+
+Internet-Draft The GNU Name System July 2019
+
+
+ Figure 9
Similarly, we divide "IV" into a 128-bit initialization vector and a
128-bit initialization vector:
@@ -589,7 +632,7 @@ Internet-Draft The GNU Name System July 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 9
+ Figure 10
The keys and IVs are used for a CFB128-AES-256 and CFB128-TWOFISH-256
chained symmetric cipher. Both ciphers are used in Cipher FeedBack
@@ -598,64 +641,6 @@ Internet-Draft The GNU Name System July 2019
RDATA := AES(AES KEY, AES IV, TWOFISH(TWOFISH KEY, TWOFISH IV, BDATA))
BDATA := TWOFISH(TWOFISH KEY, TWOFISH IV, AES(AES KEY, AES IV, RDATA))
- The decrypted RDATA has the following format:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 11]
-
-Internet-Draft The GNU Name System July 2019
-
-
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | RR COUNT | EXPIRA- /
- +-----+-----+-----+-----+-----+-----+-----+-----+
- / -TION | DATA SIZE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TYPE | FLAGS |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA /
- +-----+-----+-----+-----+ /
- / +-----------------------/
- / | /
- +-----------------------+ /
- / PADDING /
- / /
-
- Figure 10
-
- where:
-
- RR COUNT A 32-bit value containing the number of variable-length
- resource records which are following after this field in network
- byte order. The resource record format is defined in Section 3.
-
- PADDING The padding MUST contain the value 0 in all octets. The
- padding MUST ensure that the size of the RDATA is a power of two.
- As a special exception, record sets with (only) a PKEY record type
- are never padded. Note that a record set with a PKEY record MUST
- NOT contain other records.
-
5. Internationalization and Character Encoding
All labels in GNS are encoded in UTF-8 [RFC3629]. This does not
@@ -663,17 +648,6 @@ Internet-Draft The GNU Name System July 2019
which are internationalized through the IDNA specifications
[RFC5890].
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 12]
-
-Internet-Draft The GNU Name System July 2019
-
-
6. Security Considerations
TODO
@@ -690,6 +664,16 @@ Internet-Draft The GNU Name System July 2019
This will be fun
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 12]
+
+Internet-Draft The GNU Name System July 2019
+
+
10. Test Vectors
The following represents a test vector for a record of type MX with a
@@ -722,14 +706,6 @@ Internet-Draft The GNU Name System July 2019
d_h :=
01fb61f482c17633
77611c4c2509e0f3
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 13]
-
-Internet-Draft The GNU Name System July 2019
-
-
81b0e7e4405c10bd
0017c802f7d32e18
@@ -746,6 +722,14 @@ Internet-Draft The GNU Name System July 2019
9bf1b49df1e120a3
20ecc9dffb68416f
11729ad878ad3bdf
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 13]
+
+Internet-Draft The GNU Name System July 2019
+
+
d0b4db2626b620d7
8e0604e4393c66a3
@@ -778,14 +762,6 @@ Internet-Draft The GNU Name System July 2019
636f6d0000000000 com | \0 | Followed by
0000000000000000 24 bytes of padding to 2^6
0000000000000000
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 14]
-
-Internet-Draft The GNU Name System July 2019
-
-
00000000
@@ -802,6 +778,14 @@ Internet-Draft The GNU Name System July 2019
SIGNATURE :=
055cb070e05fe6de r
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 14]
+
+Internet-Draft The GNU Name System July 2019
+
+
ad694a50e5b4dedd
b9fdcbdbae004f65
afc99ba9c5a3bb54___________
@@ -835,13 +819,6 @@ Internet-Draft The GNU Name System July 2019
001fd19a6406a721
713f0a0d
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 15]
-
-Internet-Draft The GNU Name System July 2019
-
-
11. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
@@ -857,6 +834,14 @@ Internet-Draft The GNU Name System July 2019
(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
<https://www.rfc-editor.org/info/rfc3492>.
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 15]
+
+Internet-Draft The GNU Name System July 2019
+
+
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
@@ -890,14 +875,6 @@ Internet-Draft The GNU Name System July 2019
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 16]
-
-Internet-Draft The GNU Name System July 2019
-
-
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
@@ -912,6 +889,15 @@ Authors' Addresses
GNUnet e.V.
Boltzmannstrasse 3
85748 Garching
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 16]
+
+Internet-Draft The GNU Name System July 2019
+
+
Germany
Email: schanzen@gnunet.org
@@ -949,4 +935,18 @@ Authors' Addresses
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Schanzenbach, et al. Expires 24 January 2020 [Page 17]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -548,16 +548,68 @@
<section numbered="true" toc="default">
<name>Block data encryption and decryption</name>
<t>
- A symmetric encryption scheme is used to en-/decrypt the "BDATA" field
- in a GNS record block. The keys are derived from the record label
- and the zone key "zk".
- Upon receiving a resource records block, first the validity of a given
- "zk_h" MUST be checked by computing "h" from "zk" and label and
- verifying that both are equal. This step is mandatory to prevent record
- spoofing.
- For decryption of the resource records block payload,
- the key material "K" and initialization vector "IV" for the
- symmetric en-/decryption are derived:
+ A symmetric encryption scheme is used to encrypt the resource records
+ set RDATA into the BDATA field of a GNS record block.
+ The wire format of the RDATA looks as follows:
+ </t>
+ <figure anchor="figure_rdata">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | RR COUNT | EXPIRA- /
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ / -TION | DATA SIZE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TYPE | FLAGS |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA SIZE | TYPE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | FLAGS | DATA /
+ +-----+-----+-----+-----+ /
+ / +-----------------------/
+ / | /
+ +-----------------------+ /
+ / PADDING /
+ / /
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ <t>where:</t>
+ <dl>
+ <dt>RR COUNT</dt>
+ <dd>
+ A 32-bit value containing the number of variable-length resource
+ records which are
+ following after this field in network byte order.
+ The resource record format is defined in <xref target="rrecords" />.
+ </dd>
+ <dt>PADDING</dt>
+ <dd>
+ The padding MUST contain the value 0 in all octets.
+ The padding MUST ensure that the size of the RDATA is a power of two.
+ As a special exception, record sets with (only) a PKEY record type
+ are never padded. Note that a record set with a PKEY record MUST NOT
+ contain other records.
+ </dd>
+
+ </dl>
+ <t>
+ Upon receiving a resource records block, first the validity of a
+ given "zk_h" MUST be checked by computing the expected "zk_h" from "zk"
+ and label (as defined in <xref target="blinding" />) and verifying that
+ both are equal. This step is mandatory to prevent record spoofing.
+ </t>
+ <t>
+ The symmetric keys and initialization vectors are derived from the
+ record label and the zone key "zk". For decryption of the resource
+ records block payload, the key material "K" and initialization vector
+ "IV" for the symmetric en-/decryption are derived as follows:
</t>
<!-- OLD VERSION
PRK_kiv := HKDF-Extract (zk, label)
@@ -624,57 +676,6 @@
RDATA := AES(AES KEY, AES IV, TWOFISH(TWOFISH KEY, TWOFISH IV, BDATA))
BDATA := TWOFISH(TWOFISH KEY, TWOFISH IV, AES(AES KEY, AES IV, RDATA))
]]></artwork>
- <t>
- The decrypted RDATA has the following format:
- </t>
- <figure anchor="figure_rdata">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | RR COUNT | EXPIRA- /
- +-----+-----+-----+-----+-----+-----+-----+-----+
- / -TION | DATA SIZE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TYPE | FLAGS |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA /
- +-----+-----+-----+-----+ /
- / +-----------------------/
- / | /
- +-----------------------+ /
- / PADDING /
- / /
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
- <t>where:</t>
- <dl>
- <dt>RR COUNT</dt>
- <dd>
- A 32-bit value containing the number of variable-length resource
- records which are
- following after this field in network byte order.
- The resource record format is defined in <xref target="rrecords" />.
- </dd>
- <dt>PADDING</dt>
- <dd>
- The padding MUST contain the value 0 in all octets.
- The padding MUST ensure that the size of the RDATA is a power of two.
-
- As a special exception, record sets with (only) a PKEY record type
- are never padded. Note that a record set with a PKEY record MUST NOT contain
- other records.
- </dd>
-
- </dl>
</section>
</section>
<section anchor="encoding" numbered="true" toc="default">
