On Oct 2, 2018, at 11:26 AM, Tony Finch <[email protected]> wrote: > > 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.
Yes, exactly. > This isn't consistent. Yes, it is. Note the difference between "need" and "want". > You aren't > taking advantage of authentication if you are vulnerable to a downgrade > attack. If I have a path with authentication and a path without, and I prefer (not demand) the path with authentication, I am taking advantage of it. > In that case the authentication is worthless. We disagree. To me (and clearly to many others), it has worth when it is used. > >>> 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, Why not? IP addresses work just fine in both of those cases. The web world has decided that domain names are good enough identifiers for them, so other worlds might use them as well. > so authenticated encryption needs extra deployment work > (e.g. DANE) to be reliable, DANE works as well, but it is not the only possibility, depending on your use case. If you want to stay within the single-root DNSSEC model, DANE works great today, and there have already been proposals here for protocol extensions to make domain names and IP addresses work as well if we authenticate them on the parent side of a zone cut. > 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. Again, we disagree. Some resolver operators want to get good security when they can get it, and are willing to do a little work to get it. > 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. Yes, that would be good to say. :-) It then does not denigrate the people who don't need strict security but want to use what RFC 7435 describes as opportunistic. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
