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

[Viktor Dukhovni <[e-mail]>]

> On Apr 26, 2018, at 10:50 AM, Eric Rescorla <[e-mail]> wrote:
> 
>> If we look at Expect-CT and MTA-STS + companion SMTP-TLSRPT we
>> find:
>> 
>>   * a lifetime field
>>   * enforce vs. test
>>   * a report URI
>> 
>> This specification is always "enforce" (though my pull request
>> changes a MUST use DANE to a SHOULD with some necessary added
>> conditions) and since the report URI is in good measure to
>> support non-enforce mode, we're back to just max-age.
>> 
> But this reinforces my point. I think we ought to have an enforce vs test flag and a report URI (and I I don't find your arguments above about why we shouldn't do this persuasive.)  Standardizing this functionality would require resolving these issues.

We should observe that "enforce vs. test" is already moot, this document
implies enforce.  If you wanted a test mode and a reporting URI, these
would have to be part of the present extension.  When the server presents
is DANE TLSA records, the client will enforce them (for just one session,
but we should assume that downgrade attacks, while evermore common are not
the norm).

The signal to do DANE (by virtue of delivering TLSA records) is the primary
change, and it is delivered via the present extension, the "pinning" we're
proposing is NOT "pinning" to deliver TLSA records and do DANE, it is merely
downgrade protection for the signalling channel!  The "pin" can be satisfied
with a denial of existence response.  Compliant servers merely need a software
capability (to send the signal), the "pin" does not enforce new security
mechanisms.

Downgrade protection for DANE signalling DOES NOT need any of those other
bells and whistles.  They would, if needed, belong in this specification,
not in a tweak to harden the signalling.

-- 
	Viktor.