On Wed, May 3, 2017 at 7:31 PM, Martin Thomson <[email protected]> wrote:
> A clear delineation of security properties exists, if the handshake is > done, then you are in the clear. Otherwise, beware. The separation > of the streams doesn't help if you consider the possibility that 0-RTT > data can be retroactively blessed. > > I agree that it's complicated and we'll need to learn more. I fully > appreciate that you want to be conservative in how to implement this > feature. As a predominantly client stack with far fewer consumers, I > guess we are taking a few more liberties. Are we not both entitled to > our own approaches in this regard? > I just wanted to chime in on this thread too and this: I think that single-stream is the way to go .. if servers prevent 0-RTT replays. That does leave the DKG attack, but I think that's ok. That might seem like a contradictory view from me, so here's my nuanced take: * The DKG attack is real and does cause the client to repeat a request. * It's basically impossible for the server to do anything about it. The ticket isn't re-used, so clever tricks like CloudFlare's X- header don't work here. I thought for a while that the server could maybe fingerprint the plaintext, but even that doesn't work, because a client might repeat it intentionally. * Thankfully this doesn't have to be a show-stopper. The failure mode is, I think, identical to existing time outs. The client knows that the request may have succeeded, or may have failed. At that point it's up to the client what to do. Browsers retry, makes sense for them. Other clients don't, good for them. But they get to choose; and it's compatible with today's behavior. From the server's perspective, the same is true - the server knows that the original client may not have received any response, because that connection fails. * So in broad terms, existing client and server behavior should cover us here; all of this happens when connections time out today - and an attacker can already cause that to happen. It's not a big ecosystem change to the layering we have already. * If the above logic holds; then the whole "needs a profile" stuff and signaling early data and application data to applications separately is needless complexity IMO. Probably more harm than good, and seems to be getting ignored anyway. > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > -- Colm
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
