On May 25, 2021, at 2:28 PM, Paul Wouters <p...@nohats.ca> wrote: > > On May 25, 2021, at 17:16, Tim Wicinski <tjw.i...@gmail.com> wrote: >> >> >> All >> >> The authors took the advice from the working group and extracted the more >> common features >> into a separate document. The chairs would like the working group to give >> some comments, as >> we feel a document like this should be considered for adoption. > > I had not responded on purpose. As indicated in the past, I find the gains of > encrypting but not authenticating authoritative servers not very useful. > > We have an existing authentication mechanism for authenticating authoritative > servers (DNSSEC) that we should spend our energy on promoting instead of > writing more RFCs about securing the transport leaving the transported data > vulnerable to manipulation by an ever more centralized resolver farm.
The question from Tim was whether draft-pp-dprive-common-features should be adopted. I believe that there there is nothing in draft-pp-dprive-common-features that would prevent a protocol proposal such as PaulW has here (even though there is no draft for it). If I'm wrong, the -common-features draft should be amended to allow authenticating based on DNSSEC, since that seems like an obvious mechanism. --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
