Subject: [TLS] Current TLS 1.3 state?

From: Watson Ladd <[email-masked]>
Date: Sun, 2 Apr 2017 12:18:27 -0600

Dear all,

Sorry if I'm asking a question already answered elsewhere, but I am
wondering what the current state of the TLS 1.3 draft is. There seem
to have been some major changes considered and put in after 27 March,
and I don't know if the formal modeling ever got back about how much
they could model/issues found.

My guess it it makes sense for everyone to read 19 so that the issues
can be fixed for 20.

Sincerely,
Watson

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Apr 2017 11:57:36 -0700

On Sun, Apr 2, 2017 at 11:18 AM, Watson Ladd <[email-masked]> wrote:

> wondering what the current state of the TLS 1.3 draft is.

We have completed a second WGLC on -19 and I intend to put out -20 this
week or early next.

> There seem

Hmmm... No major changes were made after 27 March and as far as I now
the only two technical changes we intend to make for -20 are.

1. Having an extension to signal that the client will do post-handshake
client
authentication (and otherwise forbidding it).
2. Deciding to explicitly provide an encoding for raw public keys.

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?

-Ekr

Sincerely,
> Watson
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Sam Scott <[email-masked]>
Date: Wed, 5 Apr 2017 09:44:47 +0100

> 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

 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.

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Wed, 5 Apr 2017 11:03:25 +0200

We’re hoping that the TLS:DIV workshop later this month will serve to gather some opinions from the academic community on the current spec.
https://www.mitls.org/tls:div/ <https://www.mitls.org/tls:div/>

At IEEE S&P (Oakland), there will be at least two papers on analyses of draft 18:
- A ProVerif and CryptoVerif analysis of the protocol (and a minimal reference implementation)
- A verified F* implementation of the record layer

So, putting these together with the upcoming Tamarin analysis and previously published papers on prior drafts, I think we’ll have a solid bibliography justifying the core design of TLS 1.3, especially the (EC)DHE and PSK 1-RTT handshakes along with resumption.

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.

-Karthik

> On 5 Apr 2017, at 10:44, Sam Scott <[email-masked]> 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.
> From our* point of view we're pretty happy with the current state of the spec.
> (secrecy and authentication). More specifically, we prove an absence of attacks
> 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

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 5 Apr 2017 11:24:06 -0500

On 04/05/2017 04:03 AM, Karthikeyan Bhargavan wrote:
> We’re hoping that the TLS:DIV workshop later this month will serve to
> gather some opinions from the academic community on the current spec.
> https://www.mitls.org/tls:div/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mitls.org_tls-3Adiv_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=RT4kw6b0pru9yCl-BAMGwwVVQbdcshQhWcp0gDjoAU0&s=W1pxxY_zxF0_8Wgo8PFzD8btAMyElG7AhMA_jth0VfU&e=>
>
> So, putting these together with the upcoming Tamarin analysis and
> previously published papers on prior drafts, I think we’ll have a
> solid bibliography justifying the core design of TLS 1.3, especially
> the (EC)DHE and PSK 1-RTT handshakes along with resumption.
>
> 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.
>

W.r.t. 0-RTT/0.5-RTT in particular, since applications MUST NOT use them
without an application profile specifying their use, it may be worth
analyzing the particular application profiles as well, e.g.,
https://datatracker.ietf.org/doc/html/draft-nottingham-httpbis-retry .

-Ben

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 5 Apr 2017 21:05:13 +0300

> 0-RTT, 0.5 RTT, and post-handshake authentication.

Two of those (0-RTT and post-handshake authentication) are among the
the things that scare me.

0.5-RTT less so, because unless you abuse 0-RTT, 0.5-RTT is to
_unidentified_ peer, which should limit the abuse potential
quite a bit.

Well, the protocol where PHA would have been a major problem (HTTP/2)
moved away from it, to exported authenticators...

-Ilari

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 5 Apr 2017 12:23:48 -0700

On Wed, Apr 5, 2017 at 2:03 AM, Karthikeyan Bhargavan <
[email-masked]> 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.

-- 
Colm