Hi Paul, The attack vectors and operational concerns are different for communication between the recursive-to-authoritative than for communication between the stub-to-recursive. For instance, a stub will typically communicate with one or two recursive resolvers while recursive resolvers may communicate with many authoritative resolvers - thus changing the nature of persistent TLS connections for this communication path.
The authors of [RFC8310] recognized this difference and highlight it in the Introduction section with this statement: "The proposals here might be adapted or extended in future to be used for recursive clients and authoritative servers, but this application was out of scope for the DNS PRIVate Exchange (dprive) Working Group charter at the time this document was published." Regards, Karl On 11/30/18, 12:34 PM, "Paul Wouters" <[email protected]> wrote: On Fri, 30 Nov 2018, Hollenbeck, Scott wrote: >> times have changed, and it deserves another look, but some note that says >> "If running out of resources, drop the encryption and serve DNS data in >> the clear might be needed". Ideally in a way that querying clients that >> want to insist on privacy can bail out instead of receiving cleartext. > > Possibly, but it may also be worth discussing how to avoid getting into resource exhaustion situations in the first place. Do you have any thoughts on Karl's "need for a profile of encryption standards" comment? I am not sure I see a need for a different TLS/DTLS profile compared to regular (web) based (D)TLS connections. What do you or Karl think would be different? Paul _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
