Daniel Kahn Gillmor <[email protected]> writes: > On Tue 2015-05-12 14:40:12 -0400, Simon Josefsson wrote: >> What I'm basically wondering, and advocating, is if perhaps one method >> would be sufficient. This would reduce complexity on the protocol and >> implementation level. > > I agree that a single mechanism would be cleaner, but perhaps the two > mechanisms serve different purposes? > > It seems to me that the STARTTLS variant is useful for opportunistic > dns-privacy, while the distinct-port-based TLS-wrapped variant is useful > for pre-configured non-opportunistic dns-privacy.
I think that makes sense -- pre-configured configurations will have some trust anchor considerations as well, and might as well use a dedicated port. However these two issues are probably orthogonal. The current document defines upgrade-base and port-based approach for the same opportunistic use-case. I'd still like to understand exactly what the benefit in having two mechanisms that cover the same use-case is. > People might want to argue about whether opportunistic dns-privacy is > relevant or useful, but if we concede that it does defend against some > relevant attackers, then it might be useful? Yes. > I don't imagine a "happy eyeballs" approach happening -- if someone > isn't sure which will be available, they will just use the STARTTLS > approach. If someone *is* sure, they will use DNS-over-TLS-over-TCP. The document says that the starttls approach may interact poorly with middle boxes. So it appears as if an implementation cannot be certain that either one will work, but would have to try both. I believe that leads to a lot of unwanted complexity. >> The preference in IETF has been for the inband STARTTLS approach > > I think recent discussions have indicated that there isn't any consensus > for either approach these days. see, for example, the 'is one or two > ports "more secure"' discussion in saag (hopefully i haven't greivously > misinterpreted it): > > http://thread.gmane.org/gmane.ietf.saag/4916 Yeah... I phrased that as "traditional preference" first, but I agree this is somewhat shaky. I think it is best to evaluate the use-case for DNS and not apply any rigid traditional arguments. /Simon
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
