On Oct 1, 2018, at 8:50 AM, Tony Finch <d...@dotat.at> wrote: > > Paul Hoffman <paul.hoff...@icann.org> wrote: >> >> During earlier discussions of opportunistic encryption in the IETF, >> attempted-but-not-required authentication was strongly preferred over >> "don't even attempt to authenticate". > > This is only worthwhile if there is downgrade protection, i.e. the client > needs to be able to tell if it is supposed to be able to rely on an > authentication mechanism (e.g. using DANE). Without downgrade protection > it's equivalent to encryption without authentication.
We have to be careful when we are talking about recursive resolvers. By "client" above, I think you mean "customer of the recursive resolver" and not "the side of the recursive resolver talking to authoritative servers". Brian asked for this thread to be from the perspective of a recursive resolver operator. If I were running a recursive resolver, I want to do the best job I can for my customers, in this case giving them better privacy. I cannot guarantee them great privacy, but I can make good efforts even if they don't understand those efforts, and attempted-but-not-required authentication is better effort than "don't even attempt to authenticate". Personally, I do not know of any resolver customers that require downgrade protection unless they are running the recursive resolver for just themselves. That is, "downgrade protection" means "if you cannot get an authenticated answer, you literally want no answer at all". Answers for some RRtypes, notably TLSA, require DNSSEC authentication that must have downgrade protection, but that is not what we are discussing here. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
