Hi Phillip, We appreciate the timely and thorough review. It would be helpful if you could give us some suggested texts that you would want to see.
Best wishes, Allison On Tue, Feb 1, 2022 at 10:31 Phillip Hallam-Baker via Datatracker < [email protected]> wrote: > Reviewer: Phillip Hallam-Baker > Review result: Has Issues > > The draft addresses the longstanding problem of DNS using an insecure > transport > protocol in the way that it should have been addressed from the start - > encrypting the UDP packets. It is an important and overdue addition to the > network protocol stack. > > The approach to using QUIC is about as straightforward as is possible > given the > legacy infrastructure. One area that is likely to require attention that > is not > addressed is the interaction of DNS and PKI and DHCP in the context of WiFi > roaming networks. > > The principled way to address this use case would be for WiFi networks > requiring authentication and/or agreement to terms to advertise via a > standardized interaction signaled through e.g. DHCP. But there being no > such > agreed standard, public WiFi access points engage in a wide variety of > approaches to intercepting the user's attention. Many of these intercept > DNS > connections. Thus, the assumption that DNS is insecure is built into legacy > systems. > > While the incoherence of existing infrastructure is outside the remit of > this > specification. Guidance to implementers on this point might help reduce the > amount of additional incoherence generated. Just noting that this is an > issue > might spur folk to correct this situation. > > The security considerations section forwards to RFC7858. This > specification is > six years old and represents the state of knowledge before deployment of > the > specification. Further the scope of 7858 is stub-to-recursive traffic, the > new > draft discusses zone transfer which is far outside that scope. > > The document has a privacy considerations section but all of the text would > normally come under the 'confidentiality' heading in security > considerations. > The distinction is helpful in some cases but does not appear to add much in > this one. > > The section on traffic analysis states information can be gained from > observing > packet lengths. Given the sensitivity of DNS traffic to analysis, this > seems > like a significant oversight. Even if QUIC does not provide a convenient > mechanism for doing this, it could easily be added within the DPRIVE > binding. > > >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
