Hi, 1. Some mechanism for encryption between clients and recursive resolvers
Yes. "This" should be available to all clients and, at least, optionally provided by the resolvers. There is a case for MUST. A client is a captive of their DHCP described resolver. They may choose to not use the network. 2. Trust between clients (stubs) and recursive resolvers Whether the communication to the recursive resolver is encrypted or not the resolver itself knows all queries (data and metadata). There is an implicit trust relationship between the client and recursive resolver. This is a political rather than technical issue (unless some PIR style solution is pursued) and is probably outside the scope of DPRIVE. Nonetheless, I would like to see it *highlighted* in whatever RFC is produced. 3. Recursive to Authoritative Without the possibility of encrypting this stage, the client becomes anonymous within the community that is using the recursive resolver. Encrypting this step may be "too much" for now (and it will incur challenges for auth resolvers). If omitted, I hope that the community will re-visit the issue. Note that, if we only take 1. then the case of systems which implement a local (on system) recursive resolver receive precisely no benefit. This pushes towards using available, shared, encrypted recursive resolvers which may be an intention and/or benefit. I thank the IETF for considering this significant information leakage issue, and am glad to see that a few relevant and considered solutions have emerged for further discussion. Regards, Hugo Connery -- Technical University of Denmark _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
