> On Apr 26, 2018, at 12:13 AM, Joseph Salowey <j...@salowey.net> 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 <postfix-us...@dukhovni.org> 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<1..2^16-1> + struct { + uint16 SupportLifetime; + opaque AuthenticationChain<1..2^16-1>; + } 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
