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.