IETF Last Call Review of draft-ietf-httpbis-no-vary-search-06
review-ietf-httpbis-no-vary-search-06-secdir-lc-bonnell-2026-07-22-00

Request Review of draft-ietf-httpbis-no-vary-search
Requested revision No specific revision (document currently at 08)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2026-07-28
Requested 2026-07-07
Authors Domenic Denicola , Jeremy Roman , Nidhi Jaju
I-D last updated 2026-08-12 (Latest revision 2026-08-12)
Completed reviews Genart IETF Last Call review of -06 by Mallory Knodel (diff)
Secdir IETF Last Call review of -06 by Corey Bonnell (diff)
Secdir Telechat review of -07 by Corey Bonnell (diff)
Assignment Reviewer Corey Bonnell
State Completed
Request IETF Last Call review on draft-ietf-httpbis-no-vary-search by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/TiltnNo2zz5tw4_Gy-eJfsLPX5I
Reviewed revision 06 (document currently at 08)
Result Has issues
Completed 2026-07-22
review-ietf-httpbis-no-vary-search-06-secdir-lc-bonnell-2026-07-22-00
The Security Considerations say "The main risk to be aware of is the impact of
mismatched URLs", but nowhere in this document (or in any of the normative
references) is a "mismatched URL" defined. I think this section needs to
elaborate on what this is so the guidance can be understood.

However, the most significant issue is that the Security Considerations is
seemingly written from the standpoint of a web browser. Given that non-browser
technologies also may implement this specification, I would expect this section
to contain guidance for other types of caches, especially shared caches.

A few other comments outside the Security Considerations:
1. Since Section 7 of this document replaces text in Section 4 of RFC 9111, I
would expect that this document updates RFC 9111. 2. Section 5.3 scopes the
algorithm to ASCII inputs ("To parse a key given an ASCII string keyString:"),
but the examples in 5.3.1 all contain non-ASCII code points.