Re: New Version Notification for draft-thomson-http-replay-00.txt

On Thu, Jul 20, 2017 at 09:59:39AM +0200, Martin Thomson wrote:
> On 20 July 2017 at 06:25, Willy Tarreau <> 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.


Received on Thursday, 20 July 2017 08:23:20 UTC