> On Apr 11, 2018, at 1:33 PM, Benjamin Kaduk <bka...@akamai.com> wrote: > > You say this, but to me it seems a relevant factor when determining the > target scope for the spec. That is, if some individual believes that > DANE is amazing and the Web PKI is crap, then that individual is likely > to want to see DANE take over for the Web PKI in authenticating Web TLS > connections, and as such see that as a vital motivating factor for > any work involving bundling DANE records in the TLS handshake.
My motivation for updates to the draft is that *neither* 1. WebPKI sucks, DANE rules 2. WebPKI rules, DANE sucks is a good zealous position. Each have their strengths and weaknesses. For, example, for DV certificates, I am of the opinion that DANE is more resistant to mis-issuance. Given that neither 1. or 2. is objective truth, the draft should support "restrictive" use where neither is fully trusted, and and a server operator publishes (for _443._tcp) *restrictive* DANE TLSA records with certificate usage PKIX-EE(1) or PKIX-TA(0), with the expectation that when/if browsers that adopt and support this specification they'll enforce *both* WebPKI *and* DANE. But that requires downgrade protection. This applies to not just browsers, but to any application in which the installed base is WebPKI, and DANE is of necessity incremental and so opportunistic (used when published, but not a-priori mandated). Examples, IMAP, JMAP, NTTP, XMPP, SUBMIT, LDAP, ... As it stands, this draft fails to provide the downgrade protection needed for opportunistic adoption. It mentions in Section 8 that some clients might apply an infinite pin (a fragile strategy), but fails to describe denial of existence as a valid way to comply with such a pin should TLSA records be removed. And without a server TTL hint, the infinite pins make adoption in multi-datacentre deployments impractical. The draft has a serious scope deficiency. And indeed you're right that the key issue is *scope*, but an overly narrow scope is a substantial technical issue. Further, little attention has been paid in the WG to the scope issue, and the document sailed through with discussion mostly around just the data formats, and the key issue of scope fell through the cracks. > Someone > who is less keen on DANE over the Web PKI may not share that enthusiasm > or confidence for focusing the scope on that use case. I would say that WebPKI adherents would also want to make sure that any use in existing WebPKI applications would be *restrictive* and not either WebPKI or DANE whichever is weaker. But then the draft needs to have downgrade protection, and the applications in question might (converse of RFC7672) require any DANE TLSA records with usages other than PKIX-TA(0) or PKIX-EE(1) to be treated as "unusable". So it all comes down to whether it is appropriate to go forward with a very narrow scope (perhaps even too narrow for the initial applications, but that's debatable) and ask future adopters in new spaces to write new drafts (and pay the delay of having to wait for those to get reviewed and adopted), or amend the draft to anticipate future uses beyond the immediate motivating use case. My view is clearly in favour of an anticipatory scope. Future implementors in new applications would likely not bother to start if the cost of that is going through the IETF process for a new extension to augment this one. -- Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls