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

[Viktor Dukhovni <[e-mail]>]

> On Apr 26, 2018, at 2:30 AM, Eric Rescorla <[e-mail]> wrote:
> 
> If you look at HPKP and Expect-CT, you will note that there are a number of
> other fields besides just lifetime (report-uri, include subdomains). I recognize
> that opinions vary about whether these are good, but the advantage of having
> a whole new extension is that we need not resolve those now in order to move
> this document forward.

Let's ignore HPKP, as discussed previously it is a poor analogy
here, (and, not entirely surprisingly an impractical design).
A somewhat better comparison is Expect-CT or MTA-STS.

Both of these have a max-age.  Neither of them is "forever".  We
can safely assume that *any* mechanism to negotiate downgrade
protection for this extension between server and client will
have a finite duration.

Neither of the comparison specs are TLS extensions intended to cover
a broad range of applications.  They are single application policy
mechanisms communicated via HTTP headers.

Here, our scope is *all* end-user applications that choose to use
the DNSSEC chain extension to access the server's DANE TLSA
records.

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.

> As far as I can tell, the primary disadvantage of a new
> extension is a slight increase in the size of the TLS handshake if the extension
> is used (balanced against two wasted bytes in this proposed design if it is
> not used). That doesn't seem like a good set of tradeoffs.

Well, here I appeal to Melinda's observation that specifications
need to closely consider implementation complexity, not just
specification complexity.  Indeed implementation complexity
should be the primary concern.

A major disadvantage of a separate extension (rather than
adding semantics to an existing field) is that implementations
will then need to add code to generate and consume a second
extension, integrate the new code point, handle combinatorial
logic of receiving either extension or both, ...

Including the field now removes the need to ask libraries to
add code for a second extension, complicating the API and
complicating the code that applications need to call to
make use of the combined data.

Worst case the chain extension carries an extra 16 bits of
zeros, which by the way explicitly signal: do not do
unilateral pinning.  There's really much too little to
object to and real potential benefit.

-- 
	Viktor.