> On Apr 10, 2018, at 9:48 AM, Shumon Huque <shu...@gmail.com> wrote: > > But I would also like to publish a document that has the solid > consensus of the community that is one of key potential target > consumers of this draft (web browsers and servers). So I'm giving > more weight to their views and preferences. To date, the only > people from that community that have spoken up have expressed > strong opposition to Viktor's proposed enhancement.
There'll be negligible adoption of this draft as-is by Web Server operators on the public Internet. It offers them all pain and no gain. ZERO additional security over and above what they get with Let's Encrypt, only additional operational complexity and a new way to fail when the client supports DANE and the TLSA records are stale. Outside a few bilateral or intramural arrangements for mandatory DANE by clients when accessing specific destination servers, anyone deploying the present specification for the Web, is a masochist, or simply ignorant of what they're getting. What your response omits is any sort of cost/benefit analysis of the applicability of the present proposal to the Web. To be a proponent of adoption, you need to propose a specification that delivers tangible benefits at [plausibly] acceptable cost. No amount of wishful thinking or expedited publication will lead to meaningful adoption of a technology that is all cost and no benefit. If there's a flaw in my cost/benefit analysis posted earlier in this thread, please post a correction. From: Martin Thomson <martin.thom...@gmail.com> Date: Thu, 5 Apr 2018 12:07:57 +1000 To: TLS WG <firstname.lastname@example.org> Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension [skepticism re pinning, addressed in follow-ups] Your cost benefit analysis seems about right though. To Willem's point, moving the TTL negotiation out of the TLS extension into HTTP STS metadata means that each application protocol (IMAP, JMAP, POP, SMTP submission, ...) that would employ this specification to address the "last mile" problems with DNSSEC at mobile client systems, would need to be extended with a similar protocol extension. That's rather a lot of duplicate work (and a lot more delay) for something that can be done just once and promptly in this specification. -- Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls