On Fri, Feb 14, 2014 at 7:48 PM, Paul Hoffman <[email protected]> wrote:
> On Feb 14, 2014, at 2:50 PM, James Cloos <[email protected]> wrote: > > > The only real question is whether dane-srv and dane-smtp-with-dane > > should be published as two rfcs or combined into one? > > (I'm leaning towards two, numerically adjacent.) > > With all due respect, there are other real questions, much more > significant than that one. > > One of the biggest questions that needs to be asked is not whether DANE > can be used for opportunistic protocols, because of course it can, but > whether DANE can be used to determine whether a server at a domain name > "should" be speaking TLS at the time that a client tries to connect. Viktor > makes a strong case that it does for SMTP. During the early discussions of > TLSA, many people thought it should not. > I argued for making DANE a security policy protocol at the start. Now you are wondering if what you produced works as a security policy protocol. It can but the critical mass for adoption is almost certainly too high. DNS resource records are cheap. DNS lookups are not cheap. DANE has a last mile problem because you can't know if the DNSSEC record has been stripped out by an attacker or by some local network firewall. The way to cut the Gordian knot here is to provide an efficient way to retrieve all the information necessary to set up a request in one lookup. That solves the last mile problem and the multiple lookup problem at the same time. -- Website: http://hallambaker.com/
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
