On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> > > > On Apr 26, 2018, at 2:30 AM, Eric Rescorla <e...@rtfm.com> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
