- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 20 Jul 2017 09:59:39 +0200
- To: Willy Tarreau <w@1wt.eu>
- Cc: Subodh Iyengar <subodh@fb.com>, Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 20 July 2017 at 06:25, Willy Tarreau <w@1wt.eu> wrote: >> * There is no special API to handle 0-rtt data by the TLS terminator, i.e. it is treated as a part of the same 1-rtt stream of data > > Does such an implementation really exist ? I mean, for openssl, it's clearly > different : There's a split in the community on this point. NSS merges the streams and 0-RTT reads and writes are not different from other reads and writes. > Interestingly, we started with this initially, and figured that this was > completely covered by the distinction of early data from regular data, > and caused two other issues : > - for some clients, changing a header field after a request was attempted > and before operating a retry might be complicated (ie: the retry will > very likely happen only at the transport layer) > > - whenever a proxy doesn't support early data, and would receive the whole > request over regular data, it would have to strip this header field from > the request. This results in having to deal with 3 values for this header > field to know whether an attempt to use early data was made by the client, > and whether at least one proxy in the chain received the request as early > data. > > While I agree that APIs are difficult, I tend to think that the purpose of > the draft is to explain the prerequisites to map HTTP on top of 0-RTT and > that instead of complexifying all implementations and making them more > fragile, we should rather indicate in which cases it's forbidden to enable > 0-RTT (ie: SSL implementation doesn't provide a clear distinction between > early data and regular data). This could possibly be justified by using > your attack as an example. While I think that the example is relatively far-fetched, I think that we should take the conservative approach here. It means that the client needs to strip the header field when writing. That's a little costly, but I think that we already have to deal with rebuilding requests: if 0-RTT is rejected, then you can end up having to send an h2 request with h1. We also have this same requirement to change a header field with token binding. I'll write up a PR that makes the change: it actually simplifies the spec a little.
Received on Thursday, 20 July 2017 08:00:06 UTC