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 <noreply@xxxxxxxx> 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.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
