Subject: [TLS] Remove DH-based 0-RTT

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Feb 2016 11:03:53 -0800

Now that the other issue is in the bag, let's talk about making some
real savings.

I propose that we remove DH-based 0-RTT from TLS 1.3.

As ekr's previous mail noted, the security properties of PSK-based
0-RTT and DH-based 0-RTT are almost identical.  And DH-based 0-RTT is
much more complex.

For those who love DH-based 0-RTT, and I know that some people are
fans, here's something that might make you less sad about removing it
from the core spec.  You can use DH out of band to negotiate a PSK.
You might even do this as an extension to TLS, but that's of less
value.

If you - for example - had the offline configuration from
https://unicorn-wg.github.io/tls-offline-config/  then you could
simply state that using the included configuration identifier caused
the session to have a "PSK".  That "PSK" could be a value derived from
a shared secret (g^xs) plus maybe HKDF that took the configuration as
a label input.

Then you get something that follows Hugo's existing analysis.  What
you don't get is in-TLS server configuration, but we've established
that we don't really need that.

---

From: Wan-Teh Chang <[email-masked]>
Date: Tue, 23 Feb 2016 11:24:00 -0800

DH-based 0-RTT requires server configuration, which is all public
information and can be safely stored on disk. This makes it easy to do
0-RTT after an application restart.

PSK-based 0-RTT requires PSK, which is secret key material. Storing
PSKs on disk requires special care. Without storing PSKs on disk, we
can't do 0-RTT after an application restart.

It seems sufficient to just ban client authentication in replayable
DH-based 0-RTT. Why remove DH-based 0-RTT altogether?

Wan-Teh Chang

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Feb 2016 11:38:30 -0800

> DH-based 0-RTT. Why remove DH-based 0-RTT altogether?

On the grounds that it is more complex to analyze, build, and test.
And given that deferring the feature does no significant harm to those
who want it.

I acknowledge that persistence of secrets on clients is a material
difference between that an PSK-based 0-RTT.  I just don't think that
it's a good enough reason to pay for what is a relatively expensive
feature.

---

From: Andrei Popov <[email-masked]>
Date: Tue, 23 Feb 2016 20:02:10 +0000

For general-purpose TLS stacks that have to support PSK anyway (and therefore already deal with PSK persistence issues), removing DH-based 0-RTT is a significant simplification.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Tuesday, February 23, 2016 11:39 AM
To: Wan-Teh Chang <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Remove DH-based 0-RTT

On the grounds that it is more complex to analyze, build, and test.
And given that deferring the feature does no significant harm to those who want it.

I acknowledge that persistence of secrets on clients is a material difference between that an PSK-based 0-RTT.  I just don't think that it's a good enough reason to pay for what is a relatively expensive feature.

_______________________________________________
TLS mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7cf17dcaeb65eb4ecc907e08d33c88ed75%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=iUfZJINzquzcxHr7W6Xf1bo8P34UfkneZOVwj8TjWP0%3d

---

From: Dave Garrett <[email-masked]>
Date: Tue, 23 Feb 2016 20:57:18 -0500

> You might even do this as an extension to TLS, but that's of less

I think there is a good argument for moving DH 0RTT into a TLS extension. Implementations that are explicitly not going to use it should not be expected to implement it and risk screwing it up. If we accept that premise that online DH 0RTT will be unlikely in practice, then we would be specifying it at least primarily for out-of-band use, and doing it via an extension will probably be cleaner and safer.

I would still prefer it be defined in the TLS 1.3 specification document, though optional.

Dave

---

From: Bill Cox <[email-masked]>
Date: Tue, 23 Feb 2016 18:38:31 -0800

+1

On Tue, Feb 23, 2016 at 12:02 PM, Andrei Popov <[email-masked]>
wrote:

> For general-purpose TLS stacks that have to support PSK anyway (and
> therefore already deal with PSK persistence issues), removing DH-based
> 0-RTT is a significant simplification.
>
> Cheers,
>
> Andrei
>
> difference between that an PSK-based 0-RTT.  I just don't think that it's a
> good enough reason to pay for what is a relatively expensive feature.
>
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 23 Feb 2016 22:39:37 -0500

On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett <[email-masked]>
wrote:

> I think there is a good argument for moving DH 0RTT into a TLS extension.
> Implementations that are explicitly not going to use it should not be
> expected to implement it and risk screwing it up. If we accept that premise
> that online DH 0RTT will be unlikely in practice, then we would be
> specifying it at least primarily for out-of-band use, and doing it via an
> extension will probably be cleaner and safer.
>

​Combining this comment (which I agree with) with the following comment
from Watson in another thread:

​> ​
 If they rely on extensions then either those
​> ​
extensions need to be included in the security proofs, or we need to
​> ​
make clear that they are not as secure as TLS 1.3, and that
​> ​
implementations which enable both of them can get completely wrecked
>in new and exciting ways.
​

​We get that even if it is decided not to include the DH-based 0-RTT​ as
part of mandatory-to-implement TLS 1.3, it should be defined as an
extension and as part of the TLS 1.3 document. Leaving the reduction from
this case to PSK (as Martin suggested) to popular imagination is too
dangerous. By including it as part of TLS 1.3 official text we also
encourage the groups that are currently analyzing the protocol to include
this specific mechanism in their analysis. If they find something wrong
with it then even more reason to do the analysis.

> I would still prefer it be defined in the TLS 1.3 specification document,

​I suggest to also define TLS 1.3-EZ.
A subset of core safe functionality that should address the majority of the
usage cases.

Hugo
 ​

---

From: Watson Ladd <[email-masked]>
Date: Tue, 23 Feb 2016 23:11:16 -0800

On Tue, Feb 23, 2016 at 7:39 PM, Hugo Krawczyk <[email-masked]> wrote:
> Combining this comment (which I agree with) with the following comment from
> Watson in another thread:
>
>>
> We get that even if it is decided not to include the DH-based 0-RTT as part
> of mandatory-to-implement TLS 1.3, it should be defined as an extension and
> as part of the TLS 1.3 document. Leaving the reduction from this case to PSK
> (as Martin suggested) to popular imagination is too dangerous. By including
> it as part of TLS 1.3 official text we also encourage the groups that are
> currently analyzing the protocol to include this specific mechanism in their
> analysis. If they find something wrong with it then even more reason to do
> the analysis.
>
>
>>
> I suggest to also define TLS 1.3-EZ.

I strongly encourage this proposal, and will even massacre the
markdown to attempt it. I also commit to implementing TLS 1.3-EZ in
Go, and possibly in C based on Amazon's s2n. (A trustable X509 library
in C is still beyond my reach, so that C might be server-only).

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Feb 2016 15:42:20 +0800

On Wed, Feb 24, 2016 at 3:11 PM, Watson Ladd <[email-masked]> wrote:

> >> I would still prefer it be defined in the TLS 1.3 specification
> document,
> >> though optional.
> >
> >
> markdown to attempt it.

Great. Let's sync up as we get a little closer to done.

I also commit to implementing TLS 1.3-EZ in
> in C is still beyond my reach, so that C might be server-only).

I believe Richard Barnes has already started something along these lines,
so maybe you guys could join forces (not sure how confident he is in
it).

https://github.com/bifurcation/mint

This library currently interoperates with my experimental implementation
in NSS.

-Ekr

---

From: Subodh Iyengar <[email-masked]>
Date: Wed, 24 Feb 2016 15:44:17 +0000

Removing DH based 0-RTT would make it more important to make the lifetime of the ticket enforced.

One interesting difference is that DH based 0-RTT requires proof of possession of the private key for the client to accept the connection, however PSK based 0-RTT might not be associated with a certificate at all. Thus the only way to prove that the key is still fresh is to limit the time that the PSK is valid and strictly bound that time. Unless we add a way for the client to require a server authentication during PSK resumption.

This is relevant in situations where compromise of the ephemeral key does not mean that the long term private key has been compromised like in ssl offloading type scenarios.

Subodh Iyengar
________________________________
From: TLS [[email-masked]] on behalf of Eric Rescorla [[email-masked]]
Sent: Tuesday, February 23, 2016 11:42 PM
To: Watson Ladd
Cc: [email-masked]
Subject: Re: [TLS] Remove DH-based 0-RTT

On Wed, Feb 24, 2016 at 3:11 PM, Watson Ladd <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, Feb 23, 2016 at 7:39 PM, Hugo Krawczyk <[email-masked]<mailto:[email-masked]>> wrote:
>
>
> On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett <[email-masked]<mailto:[email-masked]>>
> wrote:
>>

-Ekr

>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=EoheRUAdZH7W_a384ARn0T_WL5c3mFNpiUQPcze2j_g&s=zk_uHWMVkpGkuJ8OSCl7M6Xq8kisJzYYWzB8mlPo_ms&e=>
>
>
>
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=EoheRUAdZH7W_a384ARn0T_WL5c3mFNpiUQPcze2j_g&s=zk_uHWMVkpGkuJ8OSCl7M6Xq8kisJzYYWzB8mlPo_ms&e=>
>

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=EoheRUAdZH7W_a384ARn0T_WL5c3mFNpiUQPcze2j_g&s=zk_uHWMVkpGkuJ8OSCl7M6Xq8kisJzYYWzB8mlPo_ms&e=>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Feb 2016 07:54:27 -0800

On 24 February 2016 at 07:44, Subodh Iyengar <[email-masked]> wrote:
> Unless we add a way for the client to require a server authentication during
> PSK resumption.

I have been arguing for this now for a while.  If there is an
incentive to do "PSK resumption" (there is), and that does not provide
the client a way to verify server certificates, then clients are
forced to make a choice between performance and checking that the
server holds the private key for the certificate.  I'd like to see a
mode where 0-RTT is grafted on to a full handshake with DHE and
signing.  Unfortunately, that gives us an almost full matrix of
options:

PSK only
PSK + DHE
PSK + DHE + signing
DHE + signing

But at least we can remove "DH0RTT + DHE + signing" and maybe other
combinations (though which ones we have currently isn't 100% clear to
me).

---

From: Watson Ladd <[email-masked]>
Date: Wed, 24 Feb 2016 08:34:24 -0800

> signing.  Unfortunately, that gives us an almost full matrix of

Part of the motivation for session tickets in the first place was the
cost of signing and DH. So long as servers can negotiate a resumption
mode without these, and clients offer it, there is no liveness check.
And if we require a DH+sign every resumption, we don't gain anything
over the full exchange except 0-RTT. Why is this server liveness issue
not considered a problem for TLS 1.2 resumption?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Feb 2016 09:04:39 -0800

> not considered a problem for TLS 1.2 resumption?

It wouldn't be a requirement, merely an option.

In 1.2, resumption and false start have the same latency profile.
Here, resumption will be faster.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 24 Feb 2016 20:00:45 +0200

> PSK + DHE + signing

Be careful with that: One can get server impersonation attacks unless
one somehow binds the SS into signature (and unlike with client sigs,
there is no straightforward way).

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Feb 2016 10:08:02 -0800

> there is no straightforward way).

The key schedule, in every variation I've seen proposed, does that.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 24 Feb 2016 20:14:51 +0200

> The key schedule, in every variation I've seen proposed, does that.

The server signature is essentially over raw handshake messages, up
to and including ServerCertificate. The first message that would
depend on actual value of SS is ServerFinished, which comes after
that point...

-Ilari

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Thu, 25 Feb 2016 00:28:56 +0100

> that point…

Yes Ilari, you’re right.

In my TRON talk, I described an attack on PSK+Signature server auth
which showed that the natural way of composing PSK + Sigs won’t work.
(And no it doesn’t work for PSK-ECDHE either.)

I think the proper way to do it is that the pre_shared_key extension
should include a ps_context value derived from the PSK. E.g for resumption,
it could include the session hash of the previous connection.
For pure PSK, it could include a MAC computed using the PSK.

It is worth noting that having such a psk_context in the client hello
would’ve prevented the attack that Cremers et al found in Tamarin as well.

Best,
Karthik

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 25 Feb 2016 16:03:28 +0200

> A subset of core safe functionality that should address the majority of the

What restrictions should there be for that subset?

I think at least the following:

- No 0-RTT (if you are looking for "exciting" security analysis, this
  is the best place to look at).
- Server waits until ClientFinished before sending data (see the
  0.5-RTT thread about excitement if you don't).
- No Server configs (but this might be going anyway).
- No post-handshake client auth (dangerous if used wrong).
- No SHA1 hashalgorithm (broken!)
- No TLS-Unique (deprecated due to breakage in earlier versions)

The rest of potentially troublesome stuff seems to be extensions,
e.g. anything defining new handshake messages (except OCSP extensions,
since those messages presumably will be folded to Certificate messages).

(There's plenty of crap in the registeries, but most of it has gotten
killed off from TLS 1.3 anyway).

-Ilari