Re: Stream limits draft posted

2023年11月6日(月) 16:04 Martin Thomson <mt@lowentropy.net>:

>
> https://datatracker.ietf.org/doc/html/draft-thomson-httpbis-h2-stream-limits-00
>
> We've talked about this, but Lucas and I have scrubbed it a little.
>
> This is not a proposal that comes with a statement of "this fixes the
> problem", so the discussion we have about this will be very important.  But
> if some servers benefit from doing things this way and clients are willing
> to implement, then it might be worth doing.
>

Thank you for publishing the draft.

If the problem can be addressed by changing the specification, then that
would be great!

Regarding how, I have two comments to the current state of the draft.

One is that the current approach does not provide a hard limit on the
number of streams that can be opened; this is because until SETTINGS are
exchanged, clients can open any number of streams. As said previously [1],
IMO it would make sense to state that endpoints implementing this extension
MUST NOT open a hard-coded number of streams until it negotiates the use of
the new scheme.

Separately, I wonder if we could use a different ALPN for signalling the
use of this new extension.

As ugly as that might sound, I would point out that the primary if not sole
reason of defining this extension is to let endpoints avoid the cost of
implementing defenses for Rapid Reset attack.

But to avoid that, servers have to either refuse use of vanilla H2 somehow,
or avoid negotiating vanilla H2.

The problem of trying to refuse use of vanilla H2 after concluding the TLS
handshake is that either GOAWAY or maybe 421 have to be sent after the
client has started sending the request, so that the client replays the
request using H1. If the clients can handle that signal and replay the
request over H1, then things would be fine.

However, my concern is that not all H2 clients, especially the ones that
stream the request body, cannot replay requests. My observation is that
Expect: 100-continue is rarely used, and that means that H2 clients are
just forwarding the request body without buffering, which means they cannot
replay (or they have an unbounded buffer, because GOAWAY asking for replay
can arrive after sending a huge request).

If we could use a new ALPN to indicate the use of this extension, this
problem goes away.

Servers can simply stop supporting vanilla H2, only supporting access using
the new safe variant and HTTP/1.1.

My feeling is that that would be a better transition plan to a safer
protocol.

WDYT?

[1] https://lists.w3.org/Archives/Public/ietf-http-wg/2023OctDec/0050.html


> We have time to discuss this week.
>
> Cheers,
> Martin
>
>

-- 
Kazuho Oku