Re: [TLS] One stream to rule them all (was Re: Security review of TLS1.3 0-RTT)

On Wed, May 3, 2017 at 7:31 PM, Martin Thomson <martin.thomson@gmail.com>
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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
Colm