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

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

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

> To me, the argument against this comes down to this:  The 0RTT data has
> different security properties than the post-handshake data, and TLS
> implementations should not hide that difference from applications.
>

I absolutely agree with sentiment, but the first problem is that we've been
concentrating on the server side, where it's actually impossible.

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.

I think the only approach that actually rigorously works is the client-side
one, that I outlined. That approach isn't very relevant to browsers, who
plan to retry aggressively anyway, but I think it's the only approach that
would work for a careful client. Interestingly, it doesn't really need
separate streams for the signaling to work. Though it'd be great to see a
formal proof in something like F*, Coq or TLA+.

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. That's really very
broken and a serious violation of the transport layer contract. I think we
should be more prescriptive here and say that if there are to be these
kinds of middle-boxes, then they need to honor maximum replay windows, and
they need to only enable 0-RTT from the client back. (e.g. client enabled,
but origin disabled is actually ok, but not the other way around).

In going through all of this, I'm assuming that the server at least has a
robust mitigation against 0-RTT replay, because not doing so is clearly
broken and I'm even entertaining how it can be supported. That stateless
form of mitigation is insecure and should die. If there's a notion that
server side signaling should be kept to facilitate stateless mitigation
(which permits millions of replays) ... we shouldn't have any time for
that, because no-one has a proposal for how the secrecy attacks can be
mitigated.


-- 
Colm