some hacks in response to secdir

draft-ietf-lsvr-l3dl.xml

@@ -453,12 +453,12 @@
     Transmission Sequence Number informs the receiver that it is the
     same PDU.</t>
 
-    <t>The L3DL OPEN PDU contains an algorithm identifier, a key, and a
+    <t>The L3DL OPEN PDU contains an algorithm identifier, and a key
-    L3DL certificate, which can be used to verify signatures on
+    which can be used to verify signatures on subsequent PDUs.  This
-    subsequent PDUs.  This document describes two methods of key
+    document describes two methods of key generation and signing for use
-    generation and signing for use by L3DL, Trust On First Use (TOFU)
+    by L3DL, Trust On First Use (TOFU) and a PKI-based mechanism to
-    and a PKI-based mechanism to provide authentication as well as
+    provide authentication as well as session integrity.  See <xref
-    session integrity.  See <xref target="sigtypes"/>.</t>
+    target="sigtypes"/>.</t>
  
 <!--
     protocol "Version:8,Transmission Sequence Number:16,L:1,Datagram Number:23,Datagram Length:16,Checksum:32,Payload...:32"
@@ -1858,12 +1858,11 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
 
   <section anchor="sigtypes" title="Signature Types">
 
-      <t>The L3DL OPEN PDU contains an algorithm identifier, a key, and
+      <t>The L3DL OPEN PDU contains an algorithm identifier and a key
-      a L3DL certificate, which can be used to verify signatures on
+      which can be used to verify signatures on subsequent PDUs.  This
-      subsequent PDUs.  This document describes two methods of key
+      document describes two methods of key generation and signing for
-      generation and signing for use by L3DL, Trust On First Use (TOFU)
+      use by L3DL, Trust On First Use (TOFU) and a PKI-based mechanism
-      and a PKI-based mechanism to provide authentication as well as
+      to provide authentication as well as session integrity.</t>
-      session integrity.</t>
 
       <t>The Key in the OPEN PDU SHOULD be the public key of an asymmetric
       key pair.  The sender signs with the private key, of course.  The
@@ -1928,10 +1927,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
 	    <t>
 	      Compose the PDU, with all fields including "Sig Algo" and
 	      "Signature Length" set, but omitting the trailing
-	      "Signature" field itself.  The Certificate Length should
+	      "Signature" field itself.  This is the "message to be
-	      be zero and the Certificate field should be empty.  This
+	      signed" for purposes of the signature algorithm.
-	      is the "message to be signed" for purposes of the
-	      signature algorithm.
 	    </t>
 
 	    <t>
@@ -2108,13 +2105,13 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
 	<t>
 	  Generating and signing the OPEN PDU with the PKI method is
 	  almost the same as in <xref target="tofu-pdu-signing"/>.  The
-	  only difference is that the PKI method MUST supply the
+	  only difference is that the PKI method uses the certificate
-	  appropriate certificate in the Certificate field.
+	  supplied out of band.
 	</t>
 
 	<t>
-	  Note that the Auth Type field applies to both the Key and
+	  Note that the Auth Type field applies to the Key field and the
-	  Certificate fields.  That is: the certificate uses the same
+	  supplied certificate.  That is: the certificate uses the same
 	  certificate suite as the session keys, L3DL does not support
 	  cross-algorithm-suite certification.
 	</t> 
@@ -2131,11 +2128,10 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
 
 	<t>
 	  After extracting the Key field from the PDU but before
-	  verifying the Signature, extract the Certificate field and
+	  verifying the Signature, verfiy that the Certificate is a
-	  verfiy that the Certificate is a valid signature of the Key
+	  valid signature of the Key field, according to the rules for
-	  field, according to the rules for the signature suite
+	  the signature suite specified by Auth Type.  If this step
-	  specified by Auth Type.  If this step fails, handle as in
+	  fails, handle as in <xref target="tofu-open-verifying"/>.
-	  <xref target="tofu-open-verifying"/>.
 	</t>
 
       </section>
@@ -2159,7 +2155,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
 
 	  <t>
 	    Require TOFU: sender MUST supply key and receiver MUST
-	    check, but L3DL certificates not needed and ignored if sent.
+	    check, but L3DL certificates not needed and are ignored.
 	  </t>
 
 	  <t>
@@ -2168,8 +2164,9 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
 	  </t>
 
 	  <t>
-	    Require PKI: sender MUST supply key and L3DL certificate,
+	    Require PKI: sender MUST supply key and and L3DL certificate
-	    receiver MUST check signature and verify the L3DL certificate.
+	    MUST be supplied out of band, and the receiver MUST check
+	    the signature and verify the L3DL certificate.
 	  </t>
 
 	</list>
@@ -2329,7 +2326,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
     covering the payload.</t>
 
     <t>The PKI method offers assurance that the L3DL certificate, and
-    hence the public key, provided in the OPEN PDU are authorized
+    hence the public key provided in the OPEN PDU, are authorized
     by a central authority, e.g. the network's security team.  The
     onward assurance of talking to the same peer and data integrity are
     the same as in the TOFU method.</t>
@@ -2343,6 +2340,12 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
     <t>The REKEY PDU is open to abuse to create a signature algorithm 
     downgrade attack.</t>
 
+    <t>If L3DL is used in a WAN deployment, as opposed to tightly
+    controlled data center, the use SHOULD be restricted to iBGP peers
+    and/or eBGP confederations within the operator's scope of trust.
+    And, because of tapping and interception threats, the PKI-based
+    authourization mechanism SHOULD be used.</t>
+
     </section>
 
   <section anchor="iana" title="IANA Considerations">