Last Call Review of draft-ietf-add-svcb-dns-06
review-ietf-add-svcb-dns-06-secdir-lc-salowey-2022-07-08-00
Request | Review of | draft-ietf-add-svcb-dns |
---|---|---|
Requested revision | No specific revision (document currently at 09) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2022-07-08 | |
Requested | 2022-06-24 | |
Authors | Benjamin M. Schwartz | |
I-D last updated | 2022-07-08 | |
Completed reviews |
Intdir Last Call review of -06
by Carlos J. Bernardos
(diff)
Artart Last Call review of -06 by Martin J. Dürst (diff) Genart Last Call review of -06 by Peter E. Yee (diff) Secdir Last Call review of -06 by Joseph A. Salowey (diff) Dnsdir Last Call review of -08 by Scott Rose (diff) |
|
Assignment | Reviewer | Joseph A. Salowey |
State | Completed | |
Request | Last Call review on draft-ietf-add-svcb-dns by Security Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/secdir/9cfqEuitk7vFbxjQ8AbvNfygs80 | |
Reviewed revision | 06 (document currently at 09) | |
Result | Ready | |
Completed | 2022-07-08 |
review-ietf-add-svcb-dns-06-secdir-lc-salowey-2022-07-08-00
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is the document is ready. A few comments: - Section 8.1.2 - good description of this problem, it seems like some of this should have been discussed in the doh document, but I couldn't find any. If there is relevant considerations in the doh document then you should reference them here. It seems that the recommendation "To mitigate redirection attacks, a client of this SVCB mapping MUST NOT identify or authenticate itself when performing DNS queries, except to servers that it specifically knows are not vulnerable to such attacks." would be difficult to implement since its not clear how the client gets this information and really should be a consideration for the server implementations/deployments that require authentication. I'm not really sure what to do about this except as a consideration for a revision of DoH.