Re: [TLS] Security review of TLS1.3 0-RTT

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

On Tue, May 30, 2017 at 2:38 PM, Victor Vasiliev <[e-mail]> wrote:

> Thank you for your analysis!  I appreciate the attention to the security
> properties of the 0-RTT requests, as it is the more delicate part of the
> protocol.  It took me a while to get through the entire review, and there
> are
> many things on which I would like to comment, but if I do that for every
> one of
> them, this reply would be too long.  Hence, I’ll try to concentrate on the
> key
> points.
>

Thanks too for reading and the response!


> TLS 1.3 as-is does not remove any of the replay protection guarantees
> provided
> by TLS 1.2.  However, if the user chooses to waive said protection in
> order to
> do 0-RTT, they can do that with an API explicitly designed for that
> purpose.
>

I don't think this holds true;  the signs are that browsers and servers
will enable by default, with well-meaning limits on the kinds of requests.
But in the real-world; it'll absolutely be enabled lots, that's the point
after all. I hope we can have pervasive 0-RTT. It'll be awesome, because
the speed of light sucks.


>
> 3) Full replay protection for 0-RTT is not realistically feasible at TLS
> layer,
>    because TLS layer is not the right place for that.
>
> You’ve already pointed out the existence of the DKG attack, where the
> attacker
> forces the client to retry the request with 1-RTT.  In this scenario, the
> attacker has a buffered 0-RTT request and is ready to insert it at any
> convenient point in time, violating the initial order assumptions.
>

Yep, though as I point out too, I think the DKG attack is different from
other replay attacks in ways that matter. The only place that the DKG
attack can be mitigated is at application layer. The TLS APIs and different
streams are pointless here. And I think that's actually an ok trade-off for
some kinds of applications - I don't think it should be a blocker for
0-RTT.  I think we agree on all this.


> With respect to the non-browser HTTP applications, I am not sure I am sold
> on
> the notion of “careful clients”. My understanding is that you suggest to
> treat
>
0-RTT failure as semantically equivalent to a regular connection failure,
> under
> the assumption that all of your clients already have to handle that case
> properly.  I see how this is supposed to work out, but most systems of this
> nature work well because connections succeed most of the time -- and as
> you go
> more and more towards the path of promising full replay protection, you
> will
> break more and more 0-RTT handshakes.  Both session resumption in general
> and
> 0-RTT in particular are designed with assumption that they can be declined
> at
> any point, that this is a normal and expected event, and at worst it would
> result in a minor performance degradation; “careful clients” violate that
> assumption.
>

The careful client is just to illustrate what it takes to make a
replay-safe application on top of an eventually consistent data store model
(which isn't uncommon) ... I don't think it's that realistic either, but it
was to point out that separate streams don't help. Only timings do.


> 4) Operational experience on datacenter-local strike registers is negative.
>
> We deployed strike registers in the initial QUIC deployment, and it was an
> operational hassle, so once we discovered that they do not provide full
> replay
> protection (due to all issues outlined above), the cost/benefit analysis
> became
> decidedly not in their favor.
>

The argument about operational inconvenience is irrelevant and dangerous.
It doesn't matter that it's hard. It doesn't matter how much it costs. It's
the cost of doing 0-RTT securely. Doing it insecurely should not be an
option, and shouldn't be something specified in an RFC.


> Our deployment experience also suggests that the negative impact from
> limiting
> 0-RTT to the same datacenter is not negligible.
>

This is the terribly false premise that gets to the heart of things. You
acknowledge yourself that there are attacks. Here you argue, essentially,
that it is too inconvenient to mitigate those attacks for users. I don't
think we can seriously take that approach.

If the methods are too inconvenient, the secure alternative is to not use
0-RTT at all.

The key phrase here "the negative impact from limiting 0-RTT to the same
datacenter is not negligible" is simply utterly the wrong way around. Yes,
it's true that fewer 0-RTT sections are accepted in a datacenter-local
system than if they are globally valid; but globally valid ones are not
secure; so what's the benefit of that comparison? It's not an alternative
we can responsibly consider. The only secure comparison is to not having
0-RTT at all. At least with datacenter local 0-RTT we do get /some/ 0-RTT.

So the statement should really be "Datacenter-local 0-RTT resumption allows
us to use 0-RTT at all, which is great, considering that it would otherwise
lead to side-channel and privacy-defeating attacks. What a sad world that
would be".

It's not useful to compare secure approaches to insecure ones, we can only
consider the former. AES-GCM is a lot slower and more expensive than RC4,
but I still have to use it.


> I feel like you are underestimating the cost and complexity of the
> distributed
> solutions proposed:
>  - RAM might be cheap in a big datacenter, but on a CDN node, the
> opportunity
>    cost of not using that RAM for something else is higher.
>  - There is nothing simple about running distributed storage, given that
> on top
>    of usual operational requirements (ability to rescale and some degree of
>    fault tolerance), you also require an atomic read-and-delete.
>  - Strike registers with strong guarantees are probably even worse in that
>    regard, since inserting a strike record requires a consistent write.
>

These really suck, I agree. This is why it's so vitally important that we
agree that 0-RTT sections "MUST" be non-replayable, precisely because this
false line of logic is so mentally tempting. And because a set of providers
may be willing to make the insecure trade-off, and risk creating a "race to
the bottom" that means all deployments end up with  these insecure
configurations.

-- 
Colm