Re: Adoption call for draft-schwartz-httpbis-optimistic-upgrade

[Glenn Strauss <[e-mail]>]

On Thu, Jan 25, 2024 at 03:59:46PM +0000, Ben Schwartz wrote:
> Hi Glenn,
> 
> I agree, the standardization status of "Upgrade: HTTP/2.0" seems to be ambiguous.  In this draft version, I attempted to address it for completeness without implying that it actually exists.  I'm happy to delete or rework that section as needed.
> 
> --Ben

https://datatracker.ietf.org/doc/draft-schwartz-httpbis-optimistic-upgrade/
Section 5.1.  "HTTP"
...
> A version number of "2.0" corresponds to HTTP/2.  Every HTTP/2
> connection begins with a Client Connection Preface (Section 3.4 of
> [RFC9113]) that was selected to ensure that a compliant HTTP/1.1
> server will not process further data on this connection.  This avoids
> security issues if an "HTTP/2.0" Upgrade Token is used
> optimistically.

I propose that this paragraph be removed or replaced, since an RFC for
Upgrade: HTTP/2.0 is an Expired Internet-Draft [1]

Instead of the Upgrade: HTTP/2.0 token, the paragraph could instead
reference HTTP/2 prior knowledge, e.g.:

"Every HTTP/2 connection begins with a Client Connection Preface
(Section 3.4 of [RFC9113]) that was selected to ensure that a compliant
HTTP/1.1 server will not process further data on this connection as
HTTP/1.1 request(s).  This avoids security issues if a client sends the
HTTP/2 Connection Preface over a clear-text connection to an HTTP/2
server supporting HTTP/2 prior knowledge (Section 3.3 of [RFC9113])."

Cheers, Glenn

[1] HTTP 2.0 Negotiation draft-montenegro-httpbis-http2-negotiation-01
https://datatracker.ietf.org/doc/html/draft-montenegro-httpbis-http2-negotiation

> ________________________________
> From: Glenn Strauss <[e-mail]>
> Sent: Thursday, January 25, 2024 1:04 AM
> To: Tommy Pauly <[e-mail]>
> Cc: HTTP Working Group <[e-mail]>
> Subject: Re: Adoption call for draft-schwartz-httpbis-optimistic-upgrade
> 
> !-------------------------------------------------------------------|
>   This Message Is From an External Sender
> 
> |-------------------------------------------------------------------!
> 
> On Tue, Jan 23, 2024 at 09:41:39AM -0800, Tommy Pauly wrote:
> > Hello HTTP,
> >
> > This email starts a working group adoption call for "Security Considerations for Optimistic Use of HTTP Upgrade”, draft-schwartz-httpbis-optimistic-upgrade. Notably, this updates RFC 9298 (connect-udp, which was produced by the MASQUE WG) on how to handle HTTP Upgrade, including to disallow optimistic data sending for HTTP/1.1.
> >
> > The document can be found here:
> >
> > https://datatracker.ietf.org/doc/draft-schwartz-httpbis-optimistic-upgrade/
> > https://www.ietf.org/archive/id/draft-schwartz-httpbis-optimistic-upgrade-00.html
> >
> > This adoption call will last for 3 weeks, until Tuesday, February 13. Please reply to this email with your reviews and comments, and whether or not you think HTTPBIS should adopt this draft.
> 
> The draft section 5.1 "HTTP" mentions token "HTTP/2.0".
> 
> Is there a published RFC -- not an expired draft -- which describes
> handling of Upgrade: HTTP/2.0?  Are there any known implementations
> (client or server) which support HTTP/1.1 Upgrade: HTTP/2.0?
> 
> There is a now-obsoleted h2c token for HTTP/1.1 upgrade of clear-text
> (non-encrypted) HTTP/1.1 via HTTP/1.1 Upgrade: h2c, but h2c is
> different from Upgrade: HTTP/2.0
> 
> Thank you for pointers to Upgrade: HTTP/2.0 specifications, besides a
> brief mention of 'e.g., "2.0"' in RFC 9110 Section 18.10
> Upgrade Token Registration.
> 
> Cheers, Glenn
>