Re: Working Group Last Call: draft-ietf-httpbis-optimistic-upgrade-03

Hi,

I've reviewed the editor's copy of this document
(draft -03 plus PR #3091). Overall, it's pretty close to ready.
I wrote up a few notes:

* It might be worth a sentence or two to explain to the reader why
this isn't an issue in HTTP/2 or later.

* I can see why MT initially incorrectly parsed the update to 9298.
PR #3091 does help with that, but perhaps we make it even
more obvious. How about this:
<<
To avoid these concerns, this document replaces that text to
exclude HTTP/1.1 from any optimistic sending, as follows:
    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 because that can cause
    request smuggling attacks.
>>
Part of my motivation for this is that if we ever do a
RFC 9298bis, we can drop in the new text as-is (just with
a reference to this document) and it'll stand on its own.

* I still think that the second change to 9298 isn't helpful. It's
purely a performance improvement for something that no one
will ever implement, so I think we don't need it. I'd much rather
the scope of this document be limited to fixing security issues.

* In the section about connect-ip, can we replace
<<forbids clients from using optimistic upgrade, avoiding this
issue.>>
with
<<forbids clients from sending optimistically in HTTP/1.x,
avoiding this issue.>>? I was a bit confused at first.

Thanks,
David

PS: apologies for the delay, I was out on vacation the last two weeks

On Wed, May 14, 2025 at 10:35 PM Ben Schwartz <bemasc@meta.com> wrote:

>
> ------------------------------
> *From:* Martin Thomson <mt@lowentropy.net>
>
> > Maybe this could be made more direct, with the words (not the changes)
> saying directly what you intend.  s/To avoid these concerns, this text is
> updated as follows/To avoid these concerns, this text is updated to exclude
> HTTP/1.1 from any optimistic sending, as follows/
>
> Sure, sounds good.  Posted as
> https://github.com/httpwg/http-extensions/pull/3091.
>
> >> The vulnerability in “connect-udp” was mostly hypothetical: it requires
> >> registering Capsule Types with values that (as a varint) are also a
> >> valid HTTP method name characters
>
> > Why would you assume that the intermediary (the thing being exploited in
> the attack) would be using only approved capsules?  Isn't it possible that
> they are being supplied with the entirely of the content, not just the
> capsule innards?
>
> "connect-udp" clients normally forward untrusted UDP data, converted into
> capsules.  That's supposed to be safe.  I'm not aware of a deployment model
> in which an untrusted party would supply capsules that are included without
> inspection.  That seems more obviously dangerous, and I'm not sure it
> qualifies as "implementing connect-udp".
>
> --Ben
>