Skip to main content

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.