Fwd: Security directorate review of draft-ietf-quic-http-32

[Lars Eggert <[e-mail]>]

> Begin forwarded message:
> 
> From: "Hilarie Orman" <[e-mail]>
> Subject: Security directorate review of draft-ietf-quic-http-32
> Date: November 17, 2020 at 6:56:26 GMT+2
> To: [e-mail], [e-mail]
> Cc: [e-mail]
> Resent-From: <[e-mail]>
> Resent-From: <[e-mail]>
> Resent-To: [e-mail], [e-mail]
> Resent-To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
> Reply-To: "Hilarie Orman" <[e-mail]>
> 
> 	 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
> 
> 
>