On Oct 1, 2018, at 6:36 AM, Brian Haberman <[email protected]> wrote: > > All, > Thanks for a productive set of exchanges on the user perspective > last week! I would like the focus for this week (10/1-10/7) to be on > clarifying the requirements from the perspective of the recursive > resolver operator. So far, I have seen: > > * DNS transaction privacy w/o authentication > * DNS transaction privacy w/ authentication of the authoritative server(s) > > Do others have additional requirements?
A third one is DNS transaction privacy with attempted-but-not-required authentication. This is the opportunistic encryption scenario: a resolver wants the best transaction privacy they can get. If example.com has two nameservers, ns1.example.com and ns2.example.com, and I cannot authenticate ns1.example.com, I will prefer to use ns2.example.com because doing so make a system-in-the-middle attack harder. I might sometimes try to authenticate with ns1.example.com again so that I can then choose between them based on other attributes such as speed, but I will prioritize ability to authenticate. During earlier discussions of opportunistic encryption in the IETF, attempted-but-not-required authentication was strongly preferred over "don't even attempt to authenticate". --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
