- From: Watson Ladd <watsonbladd@gmail.com>
- Date: Wed, 22 Oct 2025 11:17:00 -0700
- To: Erik Nygren <nygren@gmail.com>
- Cc: Ben Schwartz <bemasc@meta.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Wed, Oct 22, 2025 at 11:09 AM Erik Nygren <nygren@gmail.com> wrote: > > Unassociated random numbers alone won't help enough with request desynchronization. An attacker wanting to do something could just add their own within a body to create a new request and get things desynchronized. > > It might be worth thinking about if we can ditch negotiation though and just use Begin-Headers on the first request on a persistent connection > to initialize things, where the number there is then incremented each time by cranking a PRNG seeded off the first value in request? Isn't there an interop issue? If I have A->B->C, in a chain, and A supports the protocol, and C supports it too, but B doesn't, then we have a problem as C will see requests that were supposed to be in order potentially intermixed with other things. If we had a space of one hop headers that get cleaned out when not supported it would work, but AFAIK we don't. > > Erik > > > > > On Wed, Oct 22, 2025 at 1:44 PM Ben Schwartz <bemasc@meta.com> wrote: >> >> >> >> ________________________________ >> From: Erik Nygren <nygren@gmail.com> >> Sent: Wednesday, October 22, 2025 11:34 AM >> >> >> D. Define new header fields to demarcate the header section (e.g. "Begin-Headers: (unpredictable value) ... End-Headers: (same value)"). This could be extended to cross-check the header in various ways (e.g. enumerating the payload length of each header field). >> >> ... >> >> > It's also possible that with that we could switch from HMAC-SHA256(key,serial) to something like a keyed PRNG then? >> >> Yes, but I was thinking of just using /dev/urandom. >> >> > For example, don't make the serial explicit but instead have it implicit and use: >> >> > Begin-Headers: Crypto-PRNG(key, serial*2) >> > End-Headers: Crypto-PRNG(key, serial*2+1) >> >> Why do they need to be different? Is there a way for the attacker to see the Begin-Headers field? >> >> > In that case it might also be ok to include some additional unprotected but carefully encoded information on the Begin-Headers line? >> >> Yes, or on End-Headers: >> >> GET /example HTTP/1.1 >> Begin-Headers: 3141592 >> Host: example.com >> X-Evil-Header: "value\r\nContent-Length:0\r\n\r\nPOST /..." >> Content-Length: 100 >> End-Headers: 3141592, lengths="11,1234,3" -- Astra mortemque praestare gradatim
Received on Wednesday, 22 October 2025 18:17:16 UTC