Skip to main content

Last Call Review of draft-ietf-quic-http-32
review-ietf-quic-http-32-secdir-lc-orman-2020-11-19-00

Request Review of draft-ietf-quic-http
Requested revision No specific revision (document currently at 34)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-11-16
Requested 2020-10-21
Authors Mike Bishop
I-D last updated 2020-11-19
Completed reviews Secdir Last Call review of -32 by Hilarie Orman (diff)
Genart Last Call review of -32 by Reese Enghardt (diff)
Genart Telechat review of -33 by Reese Enghardt (diff)
Assignment Reviewer Hilarie Orman
State Completed
Request Last Call review on draft-ietf-quic-http by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/gudkQVP9QheQ1PpmrIDSULiZfFs
Reviewed revision 32 (document currently at 34)
Result Ready
Completed 2020-11-16
review-ietf-quic-http-32-secdir-lc-orman-2020-11-19-00
	 Security review of Hypertext Transfer Protocol Version 3
	 draft-ietf-quic-http-32

Do not be alarmed.  I generated this review of 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
with the intent of improving security requirements and considerations
in IETF drafts.  Comments not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

This document describes "describes a mapping of HTTP semantics over
QUIC.  [... It]  also identifies HTTP/2 features that are subsumed by
QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3."

I would like to see the Security Considerations spell out exactly
what security features HTTP expects from QUIC.

There are reasonably good Security Consideration sections for
both this document and for QUIC transport. The only problem that
I have is that the authentication model for QUIC-HTTP is not
explicitly spelled out.  The only discussion is in section 3.4
Connection Reuse, and although that section may be technically
correct, I find it hard to understand.  Similarly, there is brief
mention of privacy wrt reused connections in 10.11, but that is
weak beer, simply saying that HTTP 3 prefers not to reuse connections.
And integrity of the data isn't mentioned at all, perhaps because
all this is assumed to be provided by QUIC.  Section 10.2 says that
all QUIC packets are encrypted; I'm not sure if that's true, or if
QUIC has an option for "non-modifiable" without encryption.  The
QUIC draft is 200 pages and is still in progress, ... like a wimp
I skimmed it but did not read it in detail.

Hilarie