first draft

AS207960 · Dec 12, 2024 · cbc445b · cbc445b
1 parent 35cfb76
commit cbc445b
Show file tree

Hide file tree

Showing 2 changed files with 66 additions and 6 deletions.
diff --git a/.gitignore b/.gitignore
@@ -21,3 +21,4 @@ draft-blahaj-rsc-bis.xml
 package-lock.json
 report.xml
 !requirements.txt
+.idea/
diff --git a/draft-blahaj-rsc-bis.xml b/draft-blahaj-rsc-bis.xml
@@ -9,7 +9,7 @@
 
 <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
      ipr="trust200902" submissionType="IETF" category="std" version="3" docName="draft-blahaj-rsc-bis-latest"
-     consensus="true">
+     consensus="true" updates="9323">
   <front>
     <title abbrev="RPKI Signed Checklists V2">RPKI Signed Checklists (RSCs) Version 2</title>
     <seriesInfo name="Internet-Draft" status="standard" value="draft-blahaj-rsc-bis-latest"/>
@@ -31,8 +31,9 @@
     <workgroup>SIDR Operations</workgroup>
 
     <abstract>
-      <t>This document defines an update to <xref target="RFC 9323"/> to include
-        an explicit purpose and audience for RSCs.</t>
+      <t>This document defines an update to <xref target="RFC9323"/> to include an explicit purpose and audience for RSCs.
+        This alleviates possible security vulnerabilities in the original RSC specification caused by cross-protocol attacks.
+      </t>
     </abstract>
 
     <note removeInRFC="true">
@@ -46,20 +47,70 @@
   <middle>
     <section>
       <name>Introduction</name>
-      <t></t>
+      <t>The current version of RPKI Signed Checklists <xref target="RFC9323"/> does not signal the purpose of an RSC,
+        nor its intended audience. In the context of processing by humans this is of little concern as the context in
+        which e.g. a signed PDF was sent makes its purpose evident. However, in automated machine-to-machine protocols
+        these ambiguities can lead to security vulnerabilities. This document updates RSCs to include this information
+        to make them suitable for automated processing.
+      </t>
 
       <section>
         <name>Requirements Language</name>
         <t>The key words <bcp14>MUST</bcp14>, <bcp14>MUST NOT</bcp14>, <bcp14>REQUIRED</bcp14>, <bcp14>SHALL</bcp14>,
           <bcp14>SHALL NOT</bcp14>, <bcp14>SHOULD</bcp14>, <bcp14>SHOULD NOT</bcp14>, <bcp14>RECOMMENDED</bcp14>,
           <bcp14>NOT RECOMMENDED</bcp14>, <bcp14>MAY</bcp14>, and <bcp14>OPTIONAL</bcp14> in this document are to be
           interpreted as described in
-          <xref target="BCP14"/>
-          (<xref target="RFC2119"/>,<xref target="RFC8174"/>) when,
+          <xref target="BCP14"/> (<xref target="RFC2119"/>, <xref target="RFC8174"/>) when,
           and only when, they appear in all capitals, as shown here.
         </t>
       </section>
     </section>
+
+    <section>
+      <name>Motivation for update</name>
+      <t>Protocols can assign the different meanings to the same data. In the context of human-to-human communication
+        the worst outcome of this is often a mere opportunity for a pun; however in the context of automated
+        machine-to-machine processing this can lead to serious security vulnerabilities.
+      </t>
+      <t>An RSC with ambiguous content could, for example, be used in a replay attack. One might argue that a protocol
+        which is vulnerable to such a replay attack is a poorly designed one; a counter-argument to this is that it
+        should not be possible to design such a vulnerability into a protocol built on top of RSCs.
+      </t>
+      <t>Further motivation for avoiding such ambiguity in protocols can be found in
+        <xref target="ascii-or-protobuf" format="title"/>.</t>
+    </section>
+
+    <section>
+      <name>Updates to RSCs</name>
+      <t><xref target="RFC9323"/> defines version 0 RSCs; this document defines version 1 RSCs with the following
+        modifications.</t>
+      <t>The RpkiSignedChecklist sequence is updated to the following:</t>
+      <sourcecode type="asn.1">
+RpkiSignedChecklist ::= SEQUENCE {
+  version [1]           INTEGER DEFAULT 0,
+  resources             ResourceBlock,
+  digestAlgorithm       DigestAlgorithmIdentifier,
+  checkList             SEQUENCE (SIZE(1..MAX)) OF FileNameAndHash
+  purpose               OBJECT IDENTIFIER
+  audience              OBJECT IDENTIFIER OPTIONAL }
+      </sourcecode>
+      <t>Two new fields are defined:</t>
+      <dl>
+        <dt>purpose</dt>
+        <dd>An OID indicating for which purpose this RSC was created. An OID is chosen to avoid potential clashes
+          and to allow for easy private extensibility.</dd>
+        <dt>audience</dt>
+        <dd>An OID indication for whom the RSC was created. It <bcp14>MUST</bcp14> be set unless otherwise explicitly
+          allowed for by the RSCs purpose, e.g. an RSC intended for general widespread consumption.</dd>
+      </dl>
+      <t>RSCs with version 0 are still valid, and may still be used, but <bcp14>MUST NOT</bcp14> be used in the
+        context of automated processing.</t>
+    </section>
+
+    <section>
+      <name>IANA Considerations</name>
+      <t>This document contains no IANA considerations</t>
+    </section>
   </middle>
 
   <back>
@@ -77,6 +128,14 @@
       </references>
       <references>
         <name>Informative References</name>
+
+        <reference anchor="ascii-or-protobuf" target="https://sandstorm.io/news/2015-05-01-is-that-ascii-or-protobuf">
+          <front>
+            <title>Is that ASCII or is it Protobuf? The importance of types in cryptographic signatures.</title>
+            <author initials="K" surname="Varda" fullname="Kenton Varda"/>
+            <date month="May" year="2015"/>
+          </front>
+        </reference>
       </references>
     </references>
   </back>