Re: [TLS] Current TLS 1.3 state?

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

On Wed, Apr 5, 2017 at 2:03 AM, Karthikeyan Bhargavan <
[e-mail]> wrote:

>
> What I am less confident about is the secure usage of features like 0-RTT,
> 0.5 RTT, and post-handshake authentication.
> Many researchers have looked at these aspects (and they can correct me if
> I am wrong) but the security guarantees we can prove for these modes is
> much more limited than for the regular 1-RTT handshake. My concern is that
> these features will inspire new usage patterns will emerge for TLS 1.3 that
> have not been adequately studied. I am not sure what we can do about that
> except maybe work harder on the security considerations.
>

I'll be at TLS:DIV and presenting on 0RTT, which is forcing me to finally
nail down all of my concerns in a more concrete and data-driven form. I do
think it's fair to say that 0RTT is known to be insecure, in the sense that
there are real-world attacks it will enable, and I haven't seen any of
those disputed. Wether we should accept those is a matter of trade-offs, I
don't think we should; they seem quite serious and really point the gun at
the feet of the user.  A warning saying 'You shouldn't use these without an
application profile' is already failing in the market; with vendors
deploying 0RTT anyway in unsafe cases. It goes against all of the neat
encapsulation we've been trying to build for secure primitives.

So for now, here's my high level summary:

Replayability issues:

0RTT data is replayable, we know this. It includes a weak clock-based
protection against against replay. If we take the CDN use-case, and
realistic values for latency and clock drift, the mitigation ends up
permitting many billions of replays. This is much much more than similar
issues that have brought up before (e.g. browser retries).

1. Applications must be coded defensively against replay - e.g. they must
be idempotency. But this is hard - and for mutating actions can only truly
be achieved with tight-bound transactions at the application layer.
Enclosing transactions don't work. But 0RTT is being incorporated "below"
the application layer in a way that is very very likely to lead to a
mis-match of expectations.

2. We can say that 0RTT shouldn't be used for non-mutating actions. But
this is bad for two reasons.

Reason "A" is that many services have throttles, even for reads, to prevent
overload and abuse. If an attacker than replay 0RTT data and exhaust a
throttle, this completes a denial of service attack,

Reason "B" is that 0RTT is a very effective way to improve the performance
of uploads. For architectural reasons, it's common for users to send photos
over messaging, and for these photos to be uploaded to storage engines over
TLS, while the URL is shared over the messaging protocol. This should be a
good and valid use of 0RTT, but it certainly mutating and requires
idempotency.

Suggested mitigation for issues 1 and 2.:
The 0RTT section should be unacknowledged at the TLS protocol layer. The
client should send it, but the TLS layer should have no knowledge of
whether or not it was decrypted/accepted. Instead the application should
either tolerate it being re-sent as part of the regular application data,
or should acknowledge it explicitly at the application layer.


Side-channel defensiveness issues:

3. Replaying 0RTT data makes statistical analysis of side-channels far
easier, at the application level and at the crypto level.

At the crypto level, 0RTT opens us up to implementation side-channels that
merely decloak the plaintext (rather than key) in a way we haven't quite
had before. The attacker can feed the cipher text billions of times and
learn things about it. The previous mitigation would help with this.

At the application level, 0RTT makes it much easier to use
application-level side channels. Here's a simple example: User requests
some content from a CDN - what was it? Suppose we have a billion candidate
URLs we want to probe and see what it was. We can make trial downloads of
our candidates from the CDN and see what's warm in the cache; that helps us
narrow it down. But with 0RTT we can also replay the request against
other/cold CDN nodes, and cause them to fetch the target resource, which
makes this kind of attack exponentially easier - to the point that it is
trivial. There are neat combinatorial techniques that make finding the
needle in the haystack easy. That's a pretty big dent in secrecy.

4. 0RTT data loses Forward Secrecy.

This is a big deal because FS is one of our goals for TLS1.3. And it's a
really big deal because 0RTT is where the most valuable parts of a session
are likely be. It's the URLs you're accessing, it's your authentication
tokens, and your credit card number. These all go in the early-phase of
real-world requests precisely because the server needs them to process. If
we don't provide FS for these, but do for the HTML you are downloading, is
that really a wise combination of trade-offs? It seems very strange.

Suggested mitigation for 3 and 4:
0RTT data shouldn't use session tickets. It should use server-side state,
like a traditional session cache, and the keys should be single-use. E.g.
use it once from the cache, and then erase it. This restores forward
secrecy, prevents replays, and also is more robust against other
side-channels (tickets are themselves more open to side-channel abuse,
because tickets are replay-able).

The counter-argument I've heard here is that "CDNs don't want server side
state". But TCP fast open already relies on server side-state, CDNs are
themselves massively distributed caches anyway, and route flaps between
nodes seem to be uncommon. I don't quite see the big deal and there doesn't
seem to be another way to provide security. Tickets with replay-ability
just don't achieve it.

I would also argue that TLS1.3 should not support tickets at all; and only
cached single-use sessions. I recognize that will take a compelling set of
arguments, and is a long way from the consensus. That's is why I'll be
presenting in more detail, including about the economics of all of this.
I'll ask for open minds.


> -Karthik
>
> On 5 Apr 2017, at 10:44, Sam Scott <[e-mail]> wrote:
>
> I don't know what the state of the various modelling efforts is, though I
> imagine
> this will be a topic at TLS:DIV at the end of the month. We did discuss
> the various
> cryptographic changes in -20 (specifically the extra key derive stages and
> the
> handshake hash reification) with a number of cryptographers before
> incorporating.
> Perhaps some of the analytic groups on-list would care to comment?
>
>
> From our* point of view we're pretty happy with the current state of the
> spec.
> Our initial results confirm that TLS achieves the core security properties
> (secrecy and authentication). More specifically, we prove an absence of
> attacks
> against those properties in our model.
>
> We're currently waiting for the last version of the spec to be finalised
> so that
> we can make a more definitive statement and share our final results.
> Although we
> do not expect our analysis to be affected by the recent changes to the
> spec, we
> will still need to update our model and re-prove everything, which is
> quite time
> consuming. We will be talking at TLS:DIV so can share more then, including
> what
> is and isn't captured by our model.
>
> * Us being the Tamarin team: Cas Cremers, Marko Horvat, Jonathan Hoyland,
> Sam Scott, and Thyla van der Merwe.
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>


-- 
Colm