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.
And some thought that it should -- IIRC, this, like many of the early DANE discussions was fairly heated, and the consensus was far from unanimous. We ended up with a number of compromises simply so that we could make progress... Again, IIRC there was a suggestion that the TLSA record should be able to signal if clients may continue without TLS / perform something analogous to HASTLS / HSTS. This could have been a single bit, or yet another byte. We decided not to do that, but I wonder if in light of recent revelations we should revisit this decision. I'm not quite sure how we'd cram this into the current record, if it should be defined in each of the "DANE with foo" docs or if it would require yet another RR type... > > Viktor's view gives us good MITM protection if the DNS channel is not broken > and the client knows the DNSSEC status of its query. It also causes messages > to be lost if there is an operational problem or even an unexpected mis-match > on the crypto desires of the client and server. It also assumes that the > person running the DNS server for a name is in active contact with the person > operating the SMTP server. > > Personally, I don't care about MITM protection if it comes at the cost of > getting more organizations to turn on opportunistic crypto. I think DANE > still has an important role in that it gives the SMTP server operator a > logging capability to see if there is an MITM. Others prefer more protection > against MITMs even in the face of preventable communication failures. Or we could give the person publishing the RR the ability to specify. > > And, to be blunt, if we think that Viktor is right about DANE for SMTP, > shouldn't DANE for HTTP have the same MITM protection and operational > downsides? Personally I think that it should, but I might be in the weeds here. W > > --Paul Hoffman > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
