Security Considerations for Optimistic Protocol Transitions in HTTP/1.1
draft-ietf-httpbis-optimistic-upgrade-06

Thanks to Watson Ladd for their secdir review

# Éric Vyncke, INT AD, comments for draft-ietf-httpbis-optimistic-upgrade-05
CC @evyncke

Thank you for the work put into this document. Usually, I like short and dense documents, but I am afraid that this I-D is too terse to the point of being not easy to understand.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Tommy Pauly for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

Other thanks to Tatuya Jinmei, the Internet directorate reviewer (at my request):
https://datatracker.ietf.org/doc/review-ietf-httpbis-optimistic-upgrade-05-intdir-telechat-jinmei-2025-09-12/ (and I have read the initial discussion)

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Lack of introduction

Like other ADs, I think that an introduction will be useful.

### Section 2

Should Upgrade be quoted to make it visible that it is a protocol item ? I.e., s/A request using Upgrade might be rejected/A request using "Upgrade" might be rejected/

### Section 3

Who is the "we" in `we call` ? The author ? The WG ? The IETF Community ? Please avoid using vague and ambiguous "we" (e.g., by using passive mode).

Probably due to my own lack of expertise in the area, but I find the explanations and examples (in this section and its sub-sections) not easy to understand.

### Section 7

Perhaps because English is not my primary language, but the title of the section includes "Guidance", i.e., it does not smell normative while it actually is.

The use of a "MUST" with an unless as in `unless the client is known to wait for a 2xx` is rather weird, but perhaps clearer than a "SHOULD" with the same unless...

How can a server check that `the client is known to wait for a 2xx` ? At the bare minimum the text should contain "how it is done is out of scope".

Thank you for providing this useful update around linking both the old and new http worlds.

I have two comments for consideration:

1. I *think* the only normaltive change is in section 5.3, to me it would be super-helpful if this was up-front so it cannot be lost.  I wonder if a few sentences in section 1 could tell the reader:
* There is a review of the background and security issues
* Consideration of the impact on HTTP Upgrade with Existing Upgrade Tokens 
- including normative changes in section 5.3
* Guidance for future use of upgrade tokens and the use of HTTP CONNECT.


2. In a similar vein, for the abstract:

The current abstract says the document "discusses the security considerations" ..., and "updates RFC 9112 and RFC 9298 to avoid related security issues". That seems true, but I wonder if it is worth saying "updates the requirements in RFC 9112 and RFC 9298 to avoid related security issues". I'd be really sad if someone glanced at the abstract and skipped it thinking it was a security discussion rather than something they needed to action.

Many thanks for resolving the DISCUSS and addressing all the comments.

Kind Regards,
Gunter Van de Velde
RTG Area Director

Thanks to the author and the WG for their work on this document.

I concur with Gorry's comments and observations.

I find it odd that the document does not have an introduction section and that may be a good place to give an overview of what the document does. More importantly, put in there forward references/pointer to the sections 5.3 and 7 - those I believe are the "normative meat" and worthy of drawing attention to up front. Essentially, same as what Gorry said.

I also agree with Gorry that the abstract wording could be updated to explain the true purpose of the document.

Section 5.3
> A client MAY optimistically start sending UDP packets in HTTP Datagrams before receiving the response to its UDP proxying request, but only if the HTTP version in use is HTTP/2 or later. Clients MUST NOT send UDP packets optimistically in HTTP/1.x due to the risk of request smuggling attacks.

The guidelines for the client are great, but shouldn’t there be a similar requirement for the server. Something along the lines of “If a server receiving UDP packets optimistically in a session that is HTTP/1.1 and has received a Upgrade Request but has not responded to that request, it should drop all the UDP packets received optimistically”.

Something similar should be mentioned in Section 7 for the CONNECT method also.

Hi Ben,

Thanks for the effort put into this well-written spec.

Please find below some minor comments:

# Please help readers to find where to look for various statements in the spec. For example:

(1)

OLD:
   In HTTP/1.1 and later, a single connection can be used for many
   requests.  In HTTP/2 and HTTP/3, these requests 

NEW:
   In HTTP/1.1 [RFC9112]  and later, a single connection can be used for many
   requests.  In HTTP/2 [RFC9113] and HTTP/3 [RFC9114], these requests 

(2) Point to where this is specified

CURRENT:
   However, in HTTP/1.1, requests are strictly sequential, and each new    
   request is distinguished implicitly by the closure of the preceding
   request.

(3) Cite 9.3.6 of 9110

CURRENT:
   The other mechanism is the HTTP CONNECT method.  

# Only when accepted

OLD:
   The server replies with a 2xx (Successful)
   response to indicate that the request was accepted and a TCP
   connection was established.  

New:
   If accepted, the server replies with a 2xx (Successful)
   response to indicate that the request was accepted and a TCP
   connection was established.  

# Definitive list or samples?

CURRENT:
   Rejections are common, and can happen for a variety of reasons.  A
   request using Upgrade might be rejected if:

Is this the definite list of conditions under which this can be rejected or these are only examples? Consider making this clear in the text.

The same applies for other similar text in the draft

# An example

CURRENT:
   In some cases, the client might expect that the protocol transition
   ^^^^^^^^^^^^
   will succeed.  

Can an example be provided here for illustration purposes?

# Registered Upgrade Tokens 

CURRENT:
   This section describes the impact of this document's considerations
   on some registered upgrade tokens that are believed to be in use at
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   
   the time of writing.

Can we cite https://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-tokens.xhtml?

# Future specifications

CURRENT:
   Future specifications for upgrade tokens should account for the
   security issues discussed here and provide clear guidance on how
   implementations can avoid them.

How this reco will be tracked?

# Consider using {:quote} to tag all the citations in the document. 

Cheers,
Med

Thank you to Paul Kyzivat for the GENART review.

### Guidance for HTTP CONNECT

```
   At the time of writing, some proxy clients are believed to be
   vulnerable as described.  As a mitigation, proxy servers MUST close
   the underlying connection when rejecting a CONNECT request, without
   processing any further requests on that connection, unless the client
   is known to wait for a 2xx (Successful) response before forwarding
   TCP payload data.  This requirement applies whether or not the
   request includes a "close" connection option.

   Note that this mitigation will frequently impair the performance of
   correctly implemented clients, especially when returning a 407 (Proxy
   Authentication Required) response.  This performance loss can be
   avoided by using HTTP/2 or HTTP/3, which are not vulnerable to this
   attack.
```

I'm struggling with the phrasing of this.

I'd try to reduce the optionality here, perhaps something like:

```
   As a mitigation, proxy servers MUST close
   the underlying connection when rejecting a CONNECT request, without
   processing any further requests on that connection, unless the client
   is known to wait for a 2xx (Successful) response before forwarding
   TCP payload data.

   At the time of writing, some proxy clients are believed to be
   vulnerable unless this mitigation is provided.

   This mitigation impairs performance, and HTTP/2 or HTTP/3 should be used instead when possible.
```