Re: [TLS] Proposed text for dnsssec chain extension draft

[Viktor Dukhovni <[e-mail]>]

> On Apr 26, 2018, at 12:13 AM, Joseph Salowey <[e-mail]> wrote:
> 
> This proposal is quite a bit more than just a two byte reserved field.

I am not sure what you mean.  The proposed text adds the field, tells
servers to set it to zero, and tells clients to treat it as though it
were zero even if a non-zero value is seen.  So far, so good right?
Please help me understand...

The only extra bit is that the client *explicitly* MUST NOT PIN when
the field is zero.  So the pinning prohibition is stronger than what
you get if you just remove description of pinning, and my bet would
be that left unsaid, and if we don't standardize downgrade-protection
in a timely manner, some clients might unilaterally decide to pin.

I did not expect prohibiting pinning at this time to be controversial.
That should have broad support.

The relevant diff is at:

  https://github.com/tlswg/dnssec-chain-extension/pull/14/commits/034da27062b53fe4a7460536187220585df13f0d

Or see below:

commit 034da27062b53fe4a7460536187220585df13f0d
Author: Viktor Dukhovni <[e-mail]>
Date:   Thu Apr 26 00:00:55 2018 -0400

    Describe new 16-bit SupportLifetime extension element
    
    This both actively inhibits "pinning" in the present,
    and serves to facilitate it in the future.

diff --git a/draft-ietf-tls-dnssec-chain-extension-08.xml b/draft-ietf-tls-dnssec-chain-extension-08.xml
index ffec606..5a4b685 100644
--- a/draft-ietf-tls-dnssec-chain-extension-08.xml
+++ b/draft-ietf-tls-dnssec-chain-extension-08.xml
@@ -304,13 +304,29 @@
 
       <figure>
         <artwork>
-
-          opaque AuthenticationChain&lt;1..2^16-1&gt;
+    struct {
+        uint16 SupportLifetime;
+        opaque AuthenticationChain&lt;1..2^16-1&gt;;
+    } DnssecChainExtension;
         </artwork>
       </figure>
 
       <t>
-    The AuthenticationChain structure is composed of a sequence of 
+      A zero "SupportLifetime" prohibits the client from unilaterally
+      requiring ongoing use of the extension based on prior observation
+      of its use (pinning).
+      </t>
+
+      <t>
+      A future specification will define the semantics of non-zero
+      values of the SupportLifetime field.  Servers implementing only
+      the present specification MUST set the SupportLifetime element
+      to zero.  Clients implementing only the present specification MUST
+      treat any value received as though it were zero.
+      </t>
+
+      <t>
+    The AuthenticationChain is composed of a sequence of
     uncompressed wire format DNS resource record sets (RRset) and 
     corresponding signatures (RRSIG) record sets.
       </t>
@@ -691,6 +707,15 @@ RRSIG(. DNSKEY)
       extension, could of course unconditionally mandate its use.
     </t>
 
+    <t>
+      Pending a future specification that defines the semantics of
+      non-zero values of the SupportLifetime element of the extension,
+      clients MUST NOT employ "pinning" to require use of the extension
+      by servers previously observed to support it.  Servers that
+      implement only this specification MUST set the SupportLifetime
+      element to zero.
+    </t>
+
     <t>
       This protocol allows TLS servers to prove that they don't have a
       signed TLSA record by returning a denial of existence chain.

-- 
	Viktor.