On Tue, May 9, 2017 at 9:00 AM, Salz, Rich <rs...@akamai.com> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
