Paul Hoffman <[email protected]> wrote: > On Oct 2, 2018, at 3:12 AM, Tony Finch <[email protected]> wrote: > > Paul Hoffman <[email protected]> wrote: > >> > >> I do not have a scenario where the client (the resolver in this case) > >> needs downgrade protection for privacy. > > > > In that case there's no need to worry about authentication at all. > > (But I disagree.) > > And I disagree that there is "no need to worry". As I said in my initial > message, a resolver operator might want to take advantage of it if it is > available.
I don't understand: first you say you don't need downgrade protection, then you say you want authentication. This isn't consistent. You aren't taking advantage of authentication if you are vulnerable to a downgrade attack. In that case the authentication is worthless. > > More generally, I don't think the term "opportunistic" is very helpful, > > ....but it is the hard-fought agreement of the IETF. See RFC 7435. Yeah, and the point I am making is that it is important to pick apart the teo options described in RFC 7435's abstract. They have very different deployment characteristics and security guarantees. For protocols like SMTP or DNS there isn't an easy identifier that can be reliably authenticated, so authenticated encryption needs extra deployment work (e.g. DANE) to be reliable, and if you do that work you get downgrade protection as a bonus. If you don't do the extra work you can do unauthenticated encryption, but you remain vulnerable to active attacks. If you do the extra work without including downgrade protection then you might as well not have bothered. Perhaps I should say that this strict security can only apply if both the server advertises it and the client looks for it; if either of those don't apply then you get unauthenticated opportunistic encryption, which is OK, but we can do better when both ends want to be secure. Tony. -- f.anthony.n.finch <[email protected]> http://dotat.at/ Biscay: Easterly 5 or 6 in far southwest, otherwise variable 3 or 4. Slight or moderate. Fair. Good. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
