Skip to main content

Last Call Review of draft-ietf-dprive-dnsoquic-08
review-ietf-dprive-dnsoquic-08-secdir-lc-hallam-baker-2022-02-01-00

Request Review of draft-ietf-dprive-dnsoquic
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2022-01-25
Requested 2022-01-11
Authors Christian Huitema , Sara Dickinson , Allison Mankin
I-D last updated 2022-02-01
Completed reviews Tsvart Last Call review of -08 by Brian Trammell (diff)
Genart Last Call review of -08 by Stewart Bryant (diff)
Secdir Last Call review of -08 by Phillip Hallam-Baker (diff)
Assignment Reviewer Phillip Hallam-Baker
State Completed
Request Last Call review on draft-ietf-dprive-dnsoquic by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/-ILndWPgdvT-ZnJiqn8oWDu6DOc
Reviewed revision 08 (document currently at 12)
Result Has issues
Completed 2022-02-01
review-ietf-dprive-dnsoquic-08-secdir-lc-hallam-baker-2022-02-01-00
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.