diff options
author | Martin Schanzenbach <schanzen@gnunet.org> | 2022-05-05 15:52:55 +0200 |
---|---|---|
committer | Martin Schanzenbach <schanzen@gnunet.org> | 2022-05-05 15:52:55 +0200 |
commit | d50b7a0448378f4f58c1c7fd4c6c3afc45ad872c (patch) | |
tree | ddf9ee372fe81fbf7e4ca218aded35e9c8e4f2a5 | |
parent | 991bb6a695a292e7cc61d2e8fcb5ccdffb7335d8 (diff) | |
download | lsd0001-d50b7a0448378f4f58c1c7fd4c6c3afc45ad872c.tar.gz lsd0001-d50b7a0448378f4f58c1c7fd4c6c3afc45ad872c.zip |
alphabetical ordering
-rw-r--r-- | draft-schanzen-gns.xml | 129 | ||||
-rw-r--r-- | rs_review_202204.txt | 69 |
2 files changed, 132 insertions, 66 deletions
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml index d47ae9c..e0b38de 100644 --- a/draft-schanzen-gns.xml +++ b/draft-schanzen-gns.xml | |||
@@ -187,23 +187,55 @@ | |||
187 | <section> | 187 | <section> |
188 | <name>Terminology</name> | 188 | <name>Terminology</name> |
189 | <dl> | 189 | <dl> |
190 | <dt>Apex Label</dt> | ||
191 | <dd> | ||
192 | This type of label is used to publish resource | ||
193 | records in a zone that can be resolved without providing a specific | ||
194 | label. It is the GNS method to provide what is the "zone apex" in DNS | ||
195 | <xref target="RFC4033"/>. | ||
196 | The apex label is represented using the character U+0040 ("@" without | ||
197 | the quotes). | ||
198 | </dd> | ||
190 | <dt>Application</dt> | 199 | <dt>Application</dt> |
191 | <dd> | 200 | <dd> |
192 | A component which uses a GNS implementation | 201 | A component which uses a GNS implementation |
193 | to resolve names into records and processes its contents. | 202 | to resolve names into records and processes its contents. |
194 | </dd> | 203 | </dd> |
195 | <dt>Resolver</dt> | 204 | <dt>Blinded Zone Key</dt> |
196 | <dd> | 205 | <dd> |
197 | The component of a GNS implementation which provides | 206 | The key derived from a zone key and a label. |
198 | the recursive name resolution logic defined in | 207 | The zone key and the blinded zone key are unlinkable without knowledge of the label. |
199 | <xref target="resolution"/>. | ||
200 | </dd> | 208 | </dd> |
201 | <dt>Zone Master</dt> | 209 | |
210 | <dt>Extension Label</dt> | ||
202 | <dd> | 211 | <dd> |
203 | The component of a GNS implementation which provides | 212 | The primary use for the extension label is in redirections where the redirection |
204 | local zone management and publication as defined in | 213 | target is defined relative to the authoritative zone of the redirection |
205 | <xref target="publish"/>. | 214 | record (<xref target="gnsrecords_redirect"/>). |
215 | The extension label is represented using the character U+002B ("+" | ||
216 | without the quotes). | ||
206 | </dd> | 217 | </dd> |
218 | <dt>Label Separator</dt> | ||
219 | <dd> | ||
220 | Labels in a name are separated using the label separator U+002E | ||
221 | ("." without the quotes). | ||
222 | In GNS, with the exceptions of zone Top-Level Domains | ||
223 | (see below) and boxed records (see <xref target="gnsrecords_box"/>), | ||
224 | every separator label in a name delegates to another zone. | ||
225 | </dd> | ||
226 | <dt>Label</dt> | ||
227 | <dd> | ||
228 | A GNS label is a label as defined in <xref target="RFC8499"/>. | ||
229 | Labels are UTF-8 strings in Unicode | ||
230 | Normalization Form C (NFC) <xref target="Unicode-UAX15"/>. | ||
231 | The apex label, label separator and the extension label have | ||
232 | special purposes in the resolution protocol which are defined | ||
233 | in the rest of the document. | ||
234 | Zone administrators <bcp14>MAY</bcp14> disallow certain labels that | ||
235 | might be easily confused with other labels through registration policies | ||
236 | (see also <xref target="security_abuse"/>). | ||
237 | </dd> | ||
238 | |||
207 | <dt>Name</dt> | 239 | <dt>Name</dt> |
208 | <dd> | 240 | <dd> |
209 | A name in GNS is a domain name as defined in <xref target="RFC8499"/> | 241 | A name in GNS is a domain name as defined in <xref target="RFC8499"/> |
@@ -219,43 +251,28 @@ | |||
219 | specific user expectations, for example according to | 251 | specific user expectations, for example according to |
220 | <xref target="Unicode-UTS46"/>. | 252 | <xref target="Unicode-UTS46"/>. |
221 | </dd> | 253 | </dd> |
222 | <dt>Label</dt> | 254 | <dt>Resolver</dt> |
223 | <dd> | ||
224 | A GNS label is a label as defined in <xref target="RFC8499"/>. | ||
225 | Labels are UTF-8 strings in Unicode | ||
226 | Normalization Form C (NFC) <xref target="Unicode-UAX15"/>. | ||
227 | The apex label, label separator and the extension label have | ||
228 | special purposes in the resolution protocol which are defined | ||
229 | in the rest of the document. | ||
230 | Zone administrators <bcp14>MAY</bcp14> disallow certain labels that | ||
231 | might be easily confused with other labels through registration policies | ||
232 | (see also <xref target="security_abuse"/>). | ||
233 | </dd> | ||
234 | <dt>Apex Label</dt> | ||
235 | <dd> | 255 | <dd> |
236 | This type of label is used to publish resource | 256 | The component of a GNS implementation which provides |
237 | records in a zone that can be resolved without providing a specific | 257 | the recursive name resolution logic defined in |
238 | label. It is the GNS method to provide what is the "zone apex" in DNS | 258 | <xref target="resolution"/>. |
239 | <xref target="RFC4033"/>. | ||
240 | The apex label is represented using the character U+0040 ("@" without | ||
241 | the quotes). | ||
242 | </dd> | 259 | </dd> |
243 | <dt>Extension Label</dt> | 260 | <dt>Resource Record</dt> |
244 | <dd> | 261 | <dd> |
245 | The primary use for the extension label is in redirections where the redirection | 262 | A GNS resource record is the information associated with a label in a |
246 | target is defined relative to the authoritative zone of the redirection | 263 | GNS zone. |
247 | record (<xref target="gnsrecords_redirect"/>). | 264 | A GNS resource record contains information as defined by its |
248 | The extension label is represented using the character U+002B ("+" | 265 | resource record type. |
249 | without the quotes). | ||
250 | </dd> | 266 | </dd> |
251 | <dt>Label Separator</dt> | 267 | <dt>Start Zone</dt> |
252 | <dd> | 268 | <dd> |
253 | Labels in a name are separated using the label separator U+002E | 269 | In order to resolve any given GNS name an initial start zone must be |
254 | ("." without the quotes). | 270 | determined for this name. |
255 | In GNS, with the exceptions of zone Top-Level Domains | 271 | The start zone can be explicitly defined through a zTLD. |
256 | (see below) and boxed records (see <xref target="gnsrecords_box"/>), | 272 | Otherwise, it is determined through a local suffix-to-zone mapping |
257 | every separator label in a name delegates to another zone. | 273 | (see <xref target="governance"/>). |
258 | </dd> | 274 | </dd> |
275 | |||
259 | <dt>Top-Level Domain</dt> | 276 | <dt>Top-Level Domain</dt> |
260 | <dd> | 277 | <dd> |
261 | The rightmost part of a GNS name is a GNS Top-Level Domain (TLD). | 278 | The rightmost part of a GNS name is a GNS Top-Level Domain (TLD). |
@@ -272,25 +289,22 @@ | |||
272 | A zone is uniquely identified by its zone key. Unlike DNS zones, | 289 | A zone is uniquely identified by its zone key. Unlike DNS zones, |
273 | a GNS zone does not need to have a SOA record under the apex label. | 290 | a GNS zone does not need to have a SOA record under the apex label. |
274 | </dd> | 291 | </dd> |
275 | <dt>Zone Type</dt> | ||
276 | <dd> | ||
277 | The type of a GNS zone determines the cipher system and binary encoding | ||
278 | format of the zone key, blinded zone keys, and signatures. | ||
279 | </dd> | ||
280 | <dt>Zone Key</dt> | 292 | <dt>Zone Key</dt> |
281 | <dd> | 293 | <dd> |
282 | A key which uniquely identifies a zone. | 294 | A key which uniquely identifies a zone. |
283 | It is usually a public key of an asymmetric key pair. | 295 | It is usually a public key of an asymmetric key pair. |
284 | </dd> | 296 | </dd> |
285 | <dt>Blinded Zone Key</dt> | ||
286 | <dd> | ||
287 | The key derived from a zone key and a label. | ||
288 | The zone key and the blinded zone key are unlinkable without knowledge of the label. | ||
289 | </dd> | ||
290 | <dt>Zone Key Derivation Function</dt> | 297 | <dt>Zone Key Derivation Function</dt> |
291 | <dd> | 298 | <dd> |
292 | The zone key derivation function (ZKDF) blinds a zone key using a label. | 299 | The zone key derivation function (ZKDF) blinds a zone key using a label. |
293 | </dd> | 300 | </dd> |
301 | |||
302 | <dt>Zone Master</dt> | ||
303 | <dd> | ||
304 | The component of a GNS implementation which provides | ||
305 | local zone management and publication as defined in | ||
306 | <xref target="publish"/>. | ||
307 | </dd> | ||
294 | <dt>Zone Owner</dt> | 308 | <dt>Zone Owner</dt> |
295 | <dd> | 309 | <dd> |
296 | The holder of the secret (typically a private key) | 310 | The holder of the secret (typically a private key) |
@@ -306,20 +320,11 @@ | |||
306 | A zTLD label sequence can only be distinguished from ordinary TLD label sequences | 320 | A zTLD label sequence can only be distinguished from ordinary TLD label sequences |
307 | by attempting to decode the labels into a zone type and zone key. | 321 | by attempting to decode the labels into a zone type and zone key. |
308 | </dd> | 322 | </dd> |
309 | <dt>Start Zone</dt> | 323 | |
310 | <dd> | 324 | <dt>Zone Type</dt> |
311 | In order to resolve any given GNS name an initial start zone must be | ||
312 | determined for this name. | ||
313 | The start zone can be explicitly defined through a zTLD. | ||
314 | Otherwise, it is determined through a local suffix-to-zone mapping | ||
315 | (see <xref target="governance"/>). | ||
316 | </dd> | ||
317 | <dt>Resource Record</dt> | ||
318 | <dd> | 325 | <dd> |
319 | A GNS resource record is the information associated with a label in a | 326 | The type of a GNS zone determines the cipher system and binary encoding |
320 | GNS zone. | 327 | format of the zone key, blinded zone keys, and signatures. |
321 | A GNS resource record contains information as defined by its | ||
322 | resource record type. | ||
323 | </dd> | 328 | </dd> |
324 | </dl> | 329 | </dl> |
325 | </section> | 330 | </section> |
diff --git a/rs_review_202204.txt b/rs_review_202204.txt index bd5c782..419dc0e 100644 --- a/rs_review_202204.txt +++ b/rs_review_202204.txt | |||
@@ -10,42 +10,91 @@ Overall, I think the use of 2119 language isn't right (e.g., there's no mandator | |||
10 | 10 | ||
11 | Some people might be offended by "limiting" IANA registrations (e.g., Sec 5.3.3's PROTO). Maybe you need to have story here and explain that is not the intent? Or not. | 11 | Some people might be offended by "limiting" IANA registrations (e.g., Sec 5.3.3's PROTO). Maybe you need to have story here and explain that is not the intent? Or not. |
12 | 12 | ||
13 | ======= Clarified as fixed bit fields by IANA, where applicable. | ||
14 | |||
13 | This seems incomplete, since an implementation needs to be able to talk to remote storage (i.e., the GET in sec 7ff), and that is not defined. Does the storage need to be globally consistent? What if two views diverge? Suggest you discuss that. Somewhat addressed in section 9.5, should be joined with the other global storage sections in my view. Okay if you disagree. | 15 | This seems incomplete, since an implementation needs to be able to talk to remote storage (i.e., the GET in sec 7ff), and that is not defined. Does the storage need to be globally consistent? What if two views diverge? Suggest you discuss that. Somewhat addressed in section 9.5, should be joined with the other global storage sections in my view. Okay if you disagree. |
14 | 16 | ||
17 | ======= TODO address this somehow? | ||
18 | |||
15 | Some minor items, or nits, follow. None of them, in my view, are intended to block publication. | 19 | Some minor items, or nits, follow. None of them, in my view, are intended to block publication. |
16 | 20 | ||
17 | Abstract, should it mention SDSI? | 21 | Abstract, should it mention SDSI? |
18 | 22 | ||
19 | Sec 1, the first two paragraphs are going to disturb some folks in the IETF DNS community. Has anyone in DNS, in particular DNSSEC, looked at this? I think the "in practice it relies on" phrase is wrong. The term "petname" should have a definition, even if something parenthetical like "petname (user's personal name for something)." The paragraph containing "In DNS terminology," is a *very nice* one. | 23 | Sec 1, the first two paragraphs are going to disturb some folks in the IETF DNS community. Has anyone in DNS, in particular DNSSEC, looked at this? I think the "in practice it relies on" phrase is wrong. The term "petname" should have a definition, even if something parenthetical like "petname (user's personal name for something)." The paragraph containing "In DNS terminology," is a *very nice* one. |
20 | 24 | ||
21 | Sec 2, the items seem in arbitrary order. Consider alphabetical or explaining the ordering. Each definition might be more clear if the repetition of the term were omitted as in: | 25 | Sec 2, the items seem in arbitrary order. Consider alphabetical or explaining the ordering. |
26 | |||
27 | ====== Alphabetical ordering. | ||
28 | |||
29 | Each definition might be more clear if the repetition of the term were omitted as in: | ||
22 | Application A component which uses a GNS implementation to ... | 30 | Application A component which uses a GNS implementation to ... |
23 | In the "Name" definition, do you mean "applications MAY *require* that ... "? Using "Zone type" as the term for cipher and encoding seemed strange to me, why not "Zone Representation" or something shorter? One or two examples before the terms, with text identifying the parts in the definition, would be helpful. | ||
24 | 31 | ||
25 | Sec 3, "cryptographically secured zones" is redundant, aren't all zones cryptographically secured? Last sentence of first paragraph repeats the definition we just read. Second para "A zone can be populated by its owner with ..." A clarification that the distributed storage isn't required by the protocol would be useful. The text introducing figure 2 makes me think it's going to show all the flows for a recursive resolution, and it is rather a high-level view. | 32 | ===== Updated wording. |
33 | |||
34 | In the "Name" definition, do you mean "applications MAY *require* that ... "? | ||
35 | |||
36 | ===== I think we could also formulate it like that. But that would be a normative statement for the application | ||
37 | as opposed to a normative statement what the GNS impl. should expect. | ||
38 | |||
39 | Using "Zone type" as the term for cipher and encoding seemed strange to me, why not "Zone Representation" or something shorter? One or two examples before the terms, with text identifying the parts in the definition, would be helpful. | ||
40 | |||
41 | ===== Unclear. | ||
42 | |||
43 | Sec 3, "cryptographically secured zones" is redundant, aren't all zones cryptographically secured? | ||
44 | |||
45 | ===== Fixed | ||
46 | |||
47 | Last sentence of first paragraph repeats the definition we just read. | ||
48 | |||
49 | ===== I don't think so. | ||
50 | |||
51 | Second para "A zone can be populated by its owner with ..." A clarification that the distributed storage isn't required by the protocol would be useful. | ||
52 | |||
53 | ===== Remove "distributed". The storage is required. | ||
26 | 54 | ||
27 | Sec 4, which user creates and manages zones? The Zone admin? The end-user? The forward ref to Section 5.1 should be before the list of algorithms in my opinion. | 55 | The text introducing figure 2 makes me think it's going to show all the flows for a recursive resolution, and it is rather a high-level view. |
56 | |||
57 | ===== That is what the figure description sais and I think this is enough for an "Overview". | ||
58 | |||
59 | Sec 4, which user creates and manages zones? The Zone admin? The end-user? | ||
60 | |||
61 | ==== TODO | ||
62 | |||
63 | The forward ref to Section 5.1 should be before the list of algorithms in my opinion. | ||
64 | |||
65 | ==== TODO. After first review I disagree as it refers to the functions which are introduced above. | ||
28 | 66 | ||
29 | Sec 4.1, maybe say "||" is the concatenation operator and that "[a..b]" is the semi-closed range from A to B-1 | 67 | Sec 4.1, maybe say "||" is the concatenation operator and that "[a..b]" is the semi-closed range from A to B-1 |
30 | 68 | ||
31 | Sec 4.2, "strictly monotonically increasing order" I think monotonically is wrong. | 69 | Sec 4.2, "strictly monotonically increasing order" I think monotonically is wrong. |
32 | 70 | ||
71 | ====== I am 95% sure that monotonically is correct when we talk about a function. Not sure about order. | ||
72 | |||
33 | Sec 5, nice to block of IANA numbers for interop. Are timestamps in GNS always 64bit microsec since 1/1/1970? Maybe add a definition or something at the top? | 73 | Sec 5, nice to block of IANA numbers for interop. Are timestamps in GNS always 64bit microsec since 1/1/1970? Maybe add a definition or something at the top? |
34 | 74 | ||
75 | ===== Subjectively I like to keep normative implementation details with the fields. | ||
76 | |||
35 | Sec 5.1, period missing in last line. | 77 | Sec 5.1, period missing in last line. |
36 | 78 | ||
79 | ======= Fixed. | ||
80 | |||
37 | Sec 5.1.1, the crypto heart starts to appear. ;) This all looks okay to me, and follows current practice. | 81 | Sec 5.1.1, the crypto heart starts to appear. ;) This all looks okay to me, and follows current practice. |
38 | 82 | ||
39 | Sec 5.1.2, "highest 32 bytes" maybe "top-most"? Nit. SignDerived is clever. Consider asking CFRG to review the crypto in Sec 5. | 83 | Sec 5.1.2, "highest 32 bytes" maybe "top-most"? Nit. SignDerived is clever. Consider asking CFRG to review the crypto in Sec 5. |
40 | 84 | ||
41 | Sec 5.2.1+5.2.2, have you thought of allowing multiple REDIRECT records to achieve some kind of load-balancing or other? | 85 | Sec 5.2.1+5.2.2, have you thought of allowing multiple REDIRECT records to achieve some kind of load-balancing or other? |
42 | 86 | ||
87 | ======= Q: Maybe we want this? CNAME did not allow this, but it seems to be used in practice occasionally https://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_07.htm#dns4-CHP-10-SECT-7.1 | ||
88 | |||
43 | Sec 5.3.1, I would think TLS SNI value is also common for LEHO data. | 89 | Sec 5.3.1, I would think TLS SNI value is also common for LEHO data. |
44 | 90 | ||
45 | Sec 5.3.3, not unlike the new SVCB RR type? | 91 | Sec 5.3.3, not unlike the new SVCB RR type? |
46 | 92 | ||
47 | Sec 6, is this whole storage strictly necessary for interop? You could split it off into a separate document. There's not enough here to implement the storage. What happens to resolution if the GET() fails? I assume that's discussed. | 93 | Sec 6, is this whole storage strictly necessary for interop? You could split it off into a separate document. There's not enough here to implement the storage. What happens to resolution if the GET() fails? I assume that's discussed. |
48 | 94 | ||
95 | ======= FIXME: We may want to consider renaming Section 6 and/or move it into a subsection of Section 5 as we do not really define the storage here. | ||
96 | ======= Record Wire Format / Record Encoding | ||
97 | |||
49 | Sec 7, the application filters record sets. Oh, that is *VERY* interesting. And that picture is starting to look familiar. Third time? | 98 | Sec 7, the application filters record sets. Oh, that is *VERY* interesting. And that picture is starting to look familiar. Third time? |
50 | 99 | ||
51 | Sec 7.1+7.2+7.3 very nice, very clear, I could implement this (modulo the storage aspect). | 100 | Sec 7.1+7.2+7.3 very nice, very clear, I could implement this (modulo the storage aspect). |
@@ -54,10 +103,22 @@ Sec 9.3 seems very important. Somewhere up near the front you should forward-li | |||
54 | 103 | ||
55 | Sec 9.4, it's difficult because it requires law enforcement, etc., to get the private key? Is that really so hard? https://xkcd.com/538/ | 104 | Sec 9.4, it's difficult because it requires law enforcement, etc., to get the private key? Is that really so hard? https://xkcd.com/538/ |
56 | 105 | ||
106 | ==== No, because of the user-centric design for delegations. TODO: Clarify again in text? | ||
107 | Because in GNS a zone does not necessarily have a single/unique parent zone. | ||
108 | The top-level domains are not enumerable. | ||
109 | The as the root zone is defined locally it is not enumerable. | ||
110 | |||
57 | Sec 9.5, "offline signing of records" not quite sure, maybe a better word, but I cannot think of one. | 111 | Sec 9.5, "offline signing of records" not quite sure, maybe a better word, but I cannot think of one. |
58 | 112 | ||
59 | Sec 9.6, this belongs with Sec 6 I think. Should the DHT be part of the zone type? | 113 | Sec 9.6, this belongs with Sec 6 I think. Should the DHT be part of the zone type? |
60 | 114 | ||
115 | ==== That is an interesting question! | ||
116 | ==== Introduce STORAGE record which defined the storage type. "Default": GNUnet. | ||
117 | ==== Storage: Typenum (GANA) + Metadata e.g. 3294 (REST) + "https://example.com". OR 0 => R5N/GNUnet w/o metadata | ||
118 | ==== Or rather not? | ||
119 | |||
61 | Sec 9.7 is good. | 120 | Sec 9.7 is good. |
62 | 121 | ||
63 | Sec 12, last sentence of paragraph 1. "given that they are built on top of the same underlying DHT storage." Does that mean *any* implementation should interoperate? Does an implementation *have to use* the DHT storage? | 122 | Sec 12, last sentence of paragraph 1. "given that they are built on top of the same underlying DHT storage." Does that mean *any* implementation should interoperate? Does an implementation *have to use* the DHT storage? |
123 | |||
124 | ===== Fixed. Only If. | ||