On Tue, Oct 16, 2018 at 06:16:22PM -0400, Daniel Kahn Gillmor wrote: > > I agree with both Tom and Viktor that the current draft seems to be > misaligned between the goals and the stated scope.
I also agree that there is some misalignment of this nature. My attempt at a root cause analysis would be that the current text in the Introduction is essentially saying "let clients in bad networks do DANE", but "doing DANE" is a fairly nebulous thing, and if different people are focusing on "doing DANE" in different ways, we can get into conflict about whether a specific proposed mechanism advances our particular goals. So what is "doing DANE", then? In the course of the on-list, off-list, side meeting and interim discussions, I've benefited greatly from hearing from a lot of experts, and I deeply appreciate the patience and persistence that the participants thereof have shown in working to advance a document in this space. It was not always easy, but I think we are making progress. In the context of this discussion, I propose that DANE is a way to allow a TLS server operator[1] to indicate to a TLS client information about how the server would like to be authenticated. The practical effect of this new source of information depends on what the client would be doing *without* the DANE information, though, since we have this large deployed base that is currently not doing DANE but could do DANE in the future. If we want to analyze the (security and other) properties of adding DANE, we must consider both the starting point and the end state. I suggest that if we limit the stated scope from an open-ended "doing DANE" to also state which cases of "doing DANE" we have analyzed (leaving open the possibility for future analysis to confirm the mechanisms we define as usable in other cases), then we can get a clear answer on whether the proposed mechanism meets the requirements of each listed case, without introducing negative externalities for either the protocol participants or the Internet as a whole. This is not to exclude the "greenfield" case, of course -- a list of cases to consider might include things like: - client does not currently exist, and insists on receiving DANE records via TLS extension; server wants to use TLSA with PKIX-{TA,EE} - client does not currently exist, and insists on receiving DANE records via TLS extension; server wants to use TLSA with DANE-{TA,EE} - client currently accepts "Web PKI" certificates but is willing to do DANE; server wants to use TLSA with PKIX-{TA,EE} - client currently accepts "Web PKI" certificates but is willing to do DANE; server wants to use TLSA with DANE-{TA,EE} - client currently will opportunistically accept any certificate but is willing to apply DANE restrictions; server wants to use TLSA with DANE-{TA,EE} - client currently will opportunistically accept any certificate but is willing to apply DANE restrictions; server wants to use TLSA with PKIX-{TA,EE} where I separate out the DANE- and PKIX- usage values since they may require a separate security analysis. (If they don't; great, we can consolidate them in the document.) I don't think we would necessarily need to come to consensus on which of these cases are "most important", so long as we can provide a mechanism that will satisfy the requirements of all cases that we want to list in the document. > I wanted the draft to be done by now because i think it will be useful > in "greenfield" scenarios -- ones where the use case itself can mandate > the extension without negotiation, but i understand Viktor's point that > without any sort of negotiated pinning mechanism, the draft is probably > not useful for non-greenfield scenarios (without pinning the existence > of the extension, it cannot reduce the attack surface represented by the > CAs, and instead only represents an additional vector of attack). Right -- if the client is currently willing to do Web PKI (or worse), an attacker that can get a bogus Web PKI (or self-signed) certificate could keep the client ignorant of the true server's preference and get the client to errenously complete a handshake. We would like a way to deprive the attacker of such a capability, though in at least some situations we cannot do so with 100% reliability. We could perhaps have a success criteria for this TLS extension (as a security mechanism), that it both: (1) provides a channel for DANE records that is reliable in the absence of an attack and (2) reduces the ability of an attacker to cause the client to ignore the server's authentication preference I think that just meeting the above two conditions could provide enough value to merit publishing, even without attempting to add something like: (3) allows the client to realistically hard-fail connections where DNSSEC validation returns bogus or indeterminate. Getting (1) is probably trivial (though with middleboxes you never know), and it seems fairly clear that a pinning scheme can provide (2). (3) is more subjective and may be hard for us to make any definitive statements about, hence my proposal to exclude it for now. -Ben [1] I feel comfortable consolidating the TLS server operator with the maintainer of the DNS entr(y|ies) for that server, since the TLSA entries must reflect the operational reality of the TLS server, and if the two entities are in conflict either can trivially cause an outage. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls