Hi Viktor, With no hats.
On Tue, Apr 10, 2018 at 10:20:01AM -0400, Viktor Dukhovni wrote: > > > > 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. I'd like to expand the discussion a little bit, on the question of what the goals of this document are, as well as that they should be. Your text above seems to imply that you see the goal of the document as being a security mechanism to DANE-authenticate TLS connections. But it's not clear to me that this is the best reading of the current document text. Re-quoting some text you had included in the thread previously: [...] The intent of this proposal is to allow TLS clients to perform DANE Authentication [RFC6698] [RFC7671] of a TLS server without performing additional DNS record lookups and incurring the associated latency penalty. It also provides the ability to avoid potential problems with TLS clients being unable to look up DANE records because of an interfering or broken middlebox on the path between the client and a DNS server [HAMPERING]. And lastly, it allows a TLS client to validate the server's DANE (TLSA) records itself without needing access to a validating DNS resolver to which it has a secure connection. This mechanism is useful for TLS applications that need to address the problems described above, typically web browsers or SIP/VoIP [RFC3261] and XMPP [RFC7590]. [...] I'd like to see if we can agree on what "the problems described above" are. I am reading the quoted text to say that the problems are: 1) needing to incur additional latency by doing DNS lookups 2) interfering/broken middleboxes that drop DANE records 3) needing a secure connection to a validating resolver While it is true that performing DANE Authentication generally does have a security role, the three items I list above are essentially matters of convenience, and not themselves relevant for security. In this sense, the immediate goal of the document is more to play a role as a transport than to provide security directly. I concede that it remains useful to consider what the client will do with the received DANE records or denial thereof, so as to not unduly block off future routes for development. But it seems at least possible to take a very broad view in this space, including even the possibility of additional TLS extensions that can modify the behavior of this one (such as a modification to provide pinning-like behavior). Such extensions could be introduced closer in time to when the desire to implement and use such behavior appears. So, can we ask ourselves what we intend to get from the document? I suspect that the vehemence of disagreement being presented stems from a disagreement in the goals we are seeking to achieve. -Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
