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

From: Lars Eggert <[email-masked]>
Date: Tue, 17 Nov 2020 07:17:15 +0200

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

---

From: Lars Eggert <[email-masked]>
Date: Tue, 17 Nov 2020 07:29:41 +0200

[CC'ing the WG]

Hi Hilarie,

thanks for the review! Since the QUIC WG uses a Github Workflow I've created a separate issue for each of the items in your review and tagged you in it, see in-line responses for the precise issue link. All issues are track in the milestone https://github.com/quicwg/base-drafts/milestone/10 <https://github.com/quicwg/base-drafts/milestone/10>

We'd appreciate it if you could coordinate with the HTTP document editor via GitHub, on the issue itself and/or any Pull Request that might be raised to address your comments.

On 2020-11-17, at 6:56, Hilarie Orman <[email-masked] <mailto:[email-masked]>> wrote:
> correct, I find it hard to understand.

https://github.com/quicwg/base-drafts/issues/4362 <https://github.com/quicwg/base-drafts/issues/4362>

> Similarly, there is brief

https://github.com/quicwg/base-drafts/issues/4363 <https://github.com/quicwg/base-drafts/issues/4363>

> QUIC has an option for "non-modifiable" without encryption.

https://github.com/quicwg/base-drafts/issues/4364 <https://github.com/quicwg/base-drafts/issues/4364>

Thanks,
Lars

> The