commit 04ac3a5a25f422027201de9c1f35d7e56d9ca05b
parent 8e684c59d2ba8cd839be2a0bbf21201aec3f910b
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Thu, 5 May 2022 16:34:52 +0200
finish first pass
Diffstat:
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -2534,7 +2534,9 @@ NICK: john (Supplemental)
by having the respective domains seized by authorities.
However, the same mechanisms can also be abused in order to impose
state censorship, which is one of the motivations behind GNS.
- Hence, such a seizure is, by design, difficult to impossible in GNS.
+ In GNS, TLDs are not enumerable. By design, the start zone of
+ the resolver is defined locally and hence such a seizure is
+ difficult and ineffective in GNS.
<!--In particular, GNS does not support WHOIS (<xref target="RFC3912" />).-->
</t>
</section>
@@ -2548,7 +2550,8 @@ NICK: john (Supplemental)
Zone administrators, and for GNS this includes end-users, are
required to responsibly and diligently protect their cryptographic
keys.
- GNS supports offline signing of records.
+ GNS supports signing records in advance ("offline") in order to
+ support processes which aim to protect private keys such as air gaps.
<!-- It does not support separate zone signing and key-signing keys
(as in <xref target="RFC6781" />) in order to provide usable security. This is not useful for any implementer -->
</t>
diff --git a/rs_review_202204.txt b/rs_review_202204.txt
@@ -14,7 +14,7 @@ Some people might be offended by "limiting" IANA registrations (e.g., Sec 5.3.3'
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.
-======= TODO address this somehow?
+======= We think 9.5 is good enough
Some minor items, or nits, follow. None of them, in my view, are intended to block publication.
@@ -37,7 +37,7 @@ 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.
-===== Unclear.
+===== Unclear, should the terminology be moved?
Sec 3, "cryptographically secured zones" is redundant, aren't all zones cryptographically secured?
@@ -111,22 +111,19 @@ Sec 9.3 seems very important. Somewhere up near the front you should forward-li
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/
-==== No, because of the user-centric design for delegations. TODO: Clarify again in text?
-Because in GNS a zone does not necessarily have a single/unique parent zone.
-The top-level domains are not enumerable.
-The as the root zone is defined locally it is not enumerable.
+===== A misunderstanding that this is related to the private keys. Added a reasoning.
Sec 9.5, "offline signing of records" not quite sure, maybe a better word, but I cannot think of one.
+==== Signing of records in advance ("offline")
+
Sec 9.6, this belongs with Sec 6 I think. Should the DHT be part of the zone type?
-==== That is an interesting question!
-==== Introduce STORAGE record which defined the storage type. "Default": GNUnet.
-==== Storage: Typenum (GANA) + Metadata e.g. 3294 (REST) + "https://example.com". OR 0 => R5N/GNUnet w/o metadata
-==== Or rather not?
+==== That is an interesting question! We could introduce STORAGE record which defined the storage type. Example: Storage: Typenum (GANA) + Metadata e.g. 3294 (REST) + "https://example.com". OR 0 => R5N/GNUnet w/o metadata
+==== But, this would require a "glue" from the delegating zone: The zone owner must know the storages where the delegated zone exists. Any changes will have delays/inconsistencies. We decided to document this for a possible update of the protocol if the need arises. For now, it would be too complex and there is no real use case for this.
Sec 9.7 is good.
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?
-===== Fixed. Only If.
+===== Fixed: Only If.
