Re: [TLS] The case for a single stream of data

[Colm MacCárthaigh <[e-mail]>]

On Tue, May 9, 2017 at 9:41 AM, Salz, Rich <[e-mail]> wrote:

> > It's actually impossible because a 0RTT request may be retried as a 1RTT
> request and there's no way to correlate the two. So when the 1RTT request
> shows up, we can't go "This might be a repeat" - for example the X- header
> trick doesn't work in this case. It's subtle, which makes it even more
> likely to trip on it.
>
> That also assumes that the 0RTT data will be a completely self-contained
> request.  I share the concern that Kyle and others have pointed out, that a
> single request will span the boundaries.
>

True; though I think the partial request case it's ok ... I think it's just
orphaned data. The mechanisms that prevent 0-RTT insertion across different
connections do seem robust.


> > I think the only approach that actually rigorously works is the
> client-side one
>
> Attackers will not use well-behaved clients; does your approach still work?
>

Yes; it's about signaling to the client that "Your data may or may not have
been received". This is an ordinary failure mode for TCP and TLS and
something many clients have careful reasoning around. The difference with
0-RTT is now there's a bigger window of time during which that request may
get received, but that's it really. If the attacker replays, then it can be
received; and the attacker can use any client, but it doesn't change the
original well-behaved client's reasoning.

>The second problem is that middle-boxes can break any signaling. For
> example a CDN or TLS accelerator may enable 0-RTT towards the back-end
> origin without enabling it to the original client. In this model, the
> client has *no* way to reason about retries or replay.
>
> A CDN is not a middlebox.  As far as the client is concerned a CDN *is*
> the origin.


No I don't think this works in transactional systems. For example; suppose
the client performs an update or write "through" the CDN, and 0-RTT is
being used on both sides. In the 0-RTT world, the CDN might be subject to
replay between the CDN and the Origin. But as defined, the actual client
gets no visibility of that. That breaks careful clients.  For example they
may get a 500 back and assume that the request failed, without knowing that
the request may be replayed any time in the next 10 seconds and therefore
succeed.

This can all be made workable though; with a careful consideration of how
the signaling propagates; that's not in the draft at this time though.


> > That's really very broken and a serious violation of the transport layer
> contract.
>
> Only if you believe CDN is a middlebox.  The transport layer contract is
> overridden by legal contracts or EULA :)
>

Of course, but I think this is a predictable security problem. The
implications are very subtle and may be exploited by attackers, while
people unknowingly enable the behavior. I realize I'm in dark corner cases
here; but I think we should approach all of this with the same rigor we
treat the TLS state machine and crypto proofs.
-- 
Colm