commit a93a252fe5e5a088faed2108cca56881091633cd
parent b0dc288c8783266eb4bcd930121669228038a0f0
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Mon, 2 Sep 2024 13:29:08 +0200
update with feedback from ise
Diffstat:
1 file changed, 37 insertions(+), 0 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -22,6 +22,7 @@
<!ENTITY RFC8032 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml">
<!ENTITY RFC8126 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
<!ENTITY RFC8174 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
+<!ENTITY RFC9458 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9458.xml">
<!ENTITY RFC9498 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9498.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
@@ -3196,6 +3197,41 @@ ComputeOutDegree(REPL_LVL, HOPCOUNT, L2NSE):
enables ad-hoc participation.
</t>
</section>
+ <section>
+ <name>Block-level confidentiality and privacy</name>
+ <t>
+ Applications using the DHT APIs to store application-specific
+ block types may have varying security and privacy requirements.
+ R<sup>5</sup>N does NOT provide any kind confidentiality or
+ privacy for blocks, for example through the use of cryptography.
+ This must be provided by the application as part of the block
+ type design.
+ One example where confidentiality and privacy are required are
+ GNS records and their record blocks as defined in
+ <xref target="RFC9498"/>.
+ Other possibilities to protect the block objects may be implemented
+ using ideas from other efforts such as Oblivious HTTP and its
+ encapsulation of HTTP requests and responses <xref target="RFC9458"/>.
+ </t>
+ </section>
+ <section>
+ <name>Protocol extensions and cryptographic agility</name>
+ <t>
+ R<sup>5</sup>N makes heavy use of the Ed25519 cryptosystem.
+ It cannot be ruled out that the relevant primitives
+ are broken at any point in the future.
+ In this case, the R<sup>5</sup>N design can be reused by modifying
+ the messages and related artifacts defined in
+ <xref target="message_components"/>.
+ In order to extend and modify the R<sup>5</sup>N protocol
+ in general and to replace cryptographic in particular,
+ new message types (<tt>MTYPE</tt> fields) can be registered in
+ <xref target="GANA"/> and the message formats updated accordingly.
+ Peers processing messages <bcp14>MUST NOT</bcp14>
+ modify the <tt>MTYPE</tt> field in order to prevent
+ possible security downgrades.
+ </t>
+ </section>
</section>
<section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name>
@@ -3338,6 +3374,7 @@ Type | Name | References | Description
&RFC6940;
&RFC8126;
&RFC8174;
+ &RFC9458;
&RFC9498;
<reference anchor="ed25519" target="http://link.springer.com/chapter/10.1007/978-3-642-23951-9_9"><front><title>High-Speed High-Security Signatures</title><author initials="D." surname="Bernstein" fullname="Daniel Bernstein"><organization>University of Illinois at Chicago</organization></author><author initials="N." surname="Duif" fullname="Niels Duif"><organization>Technische Universiteit Eindhoven</organization></author><author initials="T." surname="Lange" fullname="Tanja Lange"><organization>Technische Universiteit Eindhoven</organization></author><author initials="P." surname="Schwabe" fullname="Peter Schwabe"><organization>National Taiwan University</organization></author><author initials="B." surname="Yang" fullname="Bo-Yin Yang"><organization>Academia Sinica</organization></author><date year="2011"/></front></reference>
