- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 20 Jul 2017 10:22:49 +0200
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Subodh Iyengar <subodh@fb.com>, Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Jul 20, 2017 at 09:59:39AM +0200, Martin Thomson wrote: > 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. OK then I agree it's important to take care of this. One could say that NSS transparently merging safe and unsafe data could cause trouble over the long term and should possibly be adapted, but I don't know if that's still possible. > While I think that the example is relatively far-fetched, Well, all security-related examples seem far-fetched until they become exploitable vulnerabilities :-) > I think that > we should take the conservative approach here. I agree on being conservative, which is also why I'm trying to check if instead we could suggest not to implement it if the underlying layer doesn't provide the necessary guarantees regarding received data. Do you have contacts with the people working on NSS to know if that would be something making sense for them, based on this example ? > 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. Yes, that requires at least two distinct values as we initially had and a slightly more complex processing along the chain. That's why I'm still thinking that we could be more conservative by suggesting to only implement if 100% safe. > I'll write up a PR that makes the change: it actually simplifies the > spec a little. I'm not completely sure, as we will rely on header field values and will have to enforce correctness checks (and absence of duplication), which is a bit more painful than simply checking for header field presence to notify about a risk. Willy
Received on Thursday, 20 July 2017 08:23:20 UTC