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

[Eric Rescorla <[e-mail]>]

On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni <[e-mail]>
wrote:

>
>
> > 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.
>

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.

-Ekr