Subject: [TLS] Call for consensus: Removing DHE-based 0-RTT

From: Sean Turner <[email-masked]>
Date: Tue, 29 Mar 2016 09:11:16 -0400

All,

To make sure we’ve got a clear way forward coming out of our BA sessions, we need to make sure there’s consensus on a couple of outstanding issues.  So...

There also seems to be (rougher) consensus not to support 0-RTT via DHE  (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT mode as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT are almost identical, but 0-RTT PSK has better performance properties and is simpler to specify and implement. Note that this does not permanently preclude supporting DHE-based 0-RTT in a future extension, but it would not be in the initial TLS 1.3 RFC.

If you think that we should keep DHE-based 0-RTT please indicate so now and provide your rationale.

J&S

---

From: Bill Cox <[email-masked]>
Date: Tue, 29 Mar 2016 09:13:57 -0700

qualified +1

Qualifications: I'm speaking for me, not Google.  However, please be sure
that the final spec supports both companies that prefer stateless PSK
0-RTT, as well as stateful PSK 0-RTT, such as emulating session-caches.

As most people on this list know, stateful PSK 0-RTT can be more secure
than any scheme possible with DHE 0-RTT, stateful or not.  It is not true
that the security properties of PSK-based 0-RTT and DHE-based 0-RTT are
almost identical unless comparing stateless schemes.

Stateful PSK 0-RTT can negotiate security properties over a 1-RTT
connection and remember the results.  For example, client certificates do
not work properly over stateless 0-RTT because a proof of possession is not
possible over 0-RTT connections.  Further, full PFS _requires_ server-side
state.  The security of session-cache emulation based PSK 0-RTT can be
nearly the same as TLS 1.2 security for HTTPS, but with full PFS due to the
new RMS (session caches broke this in TLS 1.2).

I am implying nothing about Google's preference when I say that some large
companies may prefer the scalability of stateless 0-RTT, while smaller
companies may prefer the imrpoved security of stateful schemes.  Make sure
both schemes remain supported as we cut out DHE 0-RTT functionality.

Bill

On Tue, Mar 29, 2016 at 6:11 AM, Sean Turner <[email-masked]> wrote:

> All,
>
> To make sure we’ve got a clear way forward coming out of our BA sessions,
> we need to make sure there’s consensus on a couple of outstanding issues.
> So...
>
> There also seems to be (rougher) consensus not to support 0-RTT via DHE
> (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT mode
> as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT are
> almost identical, but 0-RTT PSK has better performance properties and is
> simpler to specify and implement. Note that this does not permanently
> preclude supporting DHE-based 0-RTT in a future extension, but it would not
> be in the initial TLS 1.3 RFC.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Wan-Teh Chang <[email-masked]>
Date: Tue, 29 Mar 2016 10:14:33 -0700

On Tue, Mar 29, 2016 at 6:11 AM, Sean Turner <[email-masked]> wrote:
> as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT
> are almost identical, but 0-RTT PSK has better performance properties and
> is simpler to specify and implement. Note that this does not permanently
> preclude supporting DHE-based 0-RTT in a future extension, but it would
> not be in the initial TLS 1.3 RFC.

This will remove a feature from the QUIC protocol, so I'd be
interested in hearing the QUIC team's opinion.

Since DHE-based 0-RTT is already specified in the TLS 1.3 draft, I'm
not sure if "simplier to specify" should be an important factor.
However, "simpler to implement" is an important consideration. I am
curious to know how we concluded that 0-RTT PSK is simpler to
implement. Did anyone implement both 0-RTT modes and can compare the
difficulties?

As for 0-RTT PSK having better performance, that comes at the cost of
a previous full handshake with the server. Also, TLS 1.3 clients that
want to do 0-RTT PSK across an application shutdown will need to deal
with the harder problem of storing PSKs persistently.

Wan-Teh Chang

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 29 Mar 2016 11:13:13 -0700

> with the harder problem of storing PSKs persistently.

​We've talked about losing DHE 0-RTT within the team, and have concluded
that PSK resumption should be an acceptable alternative. As you suspected
however, we have not implemented ​PSK resumption and are instead waiting
until we have a TLS 1.3 implementation which supports it which we will use
in QUIC.

Since Chrome does not persist the TLS session resumption cache to disk, we
will likely lose 0-RTT across browser restarts, which is a bit of a bummer.
It's probably not too bad, but it does likely suggest we'll need to come up
with something more complex for mobile.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Mar 2016 10:57:35 -0700

> interested in hearing the QUIC team's opinion.

I agree that this would be valuable.

> implement. Did anyone implement both 0-RTT modes and can compare the

We have a prototype 0-RTT PSK implementation and have looked at but not yet
implemented 0-RTT DHE in NSS. Based on that, my sense is that the cost of
doing any 0-RTT is the bulk of the additional effort, but that if you have
PSK already, which you probably want for ordinary resumption, then the
incremental cost of 0-RTT with PSK is less than with DHE.

> a previous full handshake with the server.

Yes, this is correct. However, that's the current design of 0-RTT DHE in
TLS 1.3 as well.

> Also, TLS 1.3 clients that

Yes, that's the major delta.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 29 Mar 2016 22:11:07 +0300

On Tue, Mar 29, 2016 at 09:13:57AM -0700, Bill Cox wrote:

> than any scheme possible with DHE 0-RTT, stateful or not. 

I disagree with this.

Both PSK and DHE can with server-side state archive best possible
security (relative to any possible scheme).

Of course, currently DHE mode is cryptographically busted. And I really
dislike seeing such modes. But the proposal for 0-RTT contexts would
fix that.

-Ilari

---

From: Wan-Teh Chang <[email-masked]>
Date: Wed, 30 Mar 2016 18:41:58 -0700

Hi Eric,

Thank you for the reply.

On Tue, Mar 29, 2016 at 10:57 AM, Eric Rescorla <[email-masked]> wrote:
>> [...] I am curious to know how we concluded that 0-RTT PSK is simpler to

By analyzing Sections 7.1 and 7.3 of draft-ietf-tls-tls13-12. I think
I understand what you meant.

For convenience I reproduce the table at the top of page 74:

   +-----------------+------------------------+------------------------+
   | Key Exchange    |     Static Secret (SS) |  Ephemeral Secret (ES) |
   +-----------------+------------------------+------------------------+
   | (EC)DHE (full   |    Client ephemeral w/ |    Client ephemeral w/ |
   | handshake)      |       server ephemeral |       server ephemeral |
   |                 |                        |                        |
   | (EC)DHE (w/     |    Client ephemeral w/ |    Client ephemeral w/ |
   | 0-RTT)          |          server static |       server ephemeral |
   |                 |                        |                        |
   | PSK             |         Pre-Shared Key |         Pre-shared key |
   |                 |                        |                        |
   | PSK + (EC)DHE   |         Pre-Shared Key |    Client ephemeral w/ |
   |                 |                        |       server ephemeral |
   +-----------------+------------------------+------------------------+

In a PSK session resumption handshake, we always use the same (third)
row, with or without 0-RTT.

On the other hand, in a full handshake, without 0-RTT we use the first
row, and with 0-RTT we use the second row.

Is this what you meant?

But if you already implemented the first row, which is a must, the
incremental effort to implement the second row seems small -- you just
need to use server static instead of server ephemeral for SS.

Wan-Teh Chang

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 Mar 2016 14:33:29 +1100

> need to use server static instead of server ephemeral for SS.

Someone recently suggested that handling the SSLv2-compatible
ClientHello was similarly easy.  It wasn't by any measure simple or
straightforward.  Sure, the request was entirely reasonable, but I now
wish I had pushed back harder.

This involves a different session transcript as input, all the
machinery involved with the ServerConfiguration message, and all the
switching logic associated with a new mode.

I'd rather reduce this to the modes that we know that we need now,
particularly since we know how we could retrofit a DH-based 0-RTT into
a PSK-based protocol.

---

From: Wan-Teh Chang <[email-masked]>
Date: Wed, 30 Mar 2016 21:52:17 -0700

Hi Martin,

>> need to use server static instead of server ephemeral for SS.
[...]
> switching logic associated with a new mode.

By "session transcript", did you mean what is now called the Handshake
Context in draft-ietf-tls-tls13-12?

For convenience, I reproduce two tables about Handshake Context from
draft-ietf-tls-tls13-12.

>From page 64:

   +----------------+-----------------------------------------+--------+
   | Mode           | Handshake Context                       | Base   |
   |                |                                         | Key    |
   +----------------+-----------------------------------------+--------+
   | 0-RTT          | ClientHello + ServerConfiguration +     | xSS    |
   |                | Server Certificate + CertificateRequest |        |
   |                | (where ServerConfiguration, etc. are    |        |
   |                | from the previous handshake)            |        |
   |                |                                         |        |
   | 1-RTT (Server) | ClientHello ... ServerConfiguration     | master |
   |                |                                         | secret |
   |                |                                         |        |
   | 1-RTT (Client) | ClientHello ... ServerFinished          | master |
   |                |                                         | secret |
   |                |                                         |        |
   | Post-Handshake | ClientHello ... ClientFinished +        | master |
   |                | CertificateRequest                      | secret |
   +----------------+-----------------------------------------+--------+

>From page 77:

   +-------------+---------+-----------------+-------------------------+
   | Record Type | Secret  | Phase           |       Handshake Context |
   +-------------+---------+-----------------+-------------------------+
   | 0-RTT       | xSS     | "early          |           ClientHello + |
   | Handshake   |         | handshake key   |   ServerConfiguration + |
   |             |         | expansion"      |      Server Certificate |
   |             |         |                 |                         |
   | 0-RTT       | xSS     | "early          |           ClientHello + |
   | Application |         | application     |   ServerConfiguration + |
   |             |         | data key        |      Server Certificate |
   |             |         | expansion"      |                         |
   |             |         |                 |                         |
   | Handshake   | xES     | "handshake key  |          ClientHello... |
   |             |         | expansion"      |             ServerHello |
   |             |         |                 |                         |
   | Application | traffic | "application    |   ClientHello... Server |
   | Data        | secret  | data key        |                Finished |
   |             |         | expansion"      |                         |
   +-------------+---------+-----------------+-------------------------+

The info is these two tables is exactly the same for DHE-based 0-RTT
and PSK-based 0-RTT. So, between the two kinds of 0-RTT, I only see a
small difference in the complexity of the key derivation process as
shown in the table at the top of page 74.

Wan-Teh Chang

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 31 Mar 2016 14:20:06 +0200

Hi Sean,

just to make sure that I properly understand the question: You are
suggesting to remove the DHE support but not the ECDHE support from the
0-RTT exchange.

Removing the DHE support is fine for us (at ARM) since we are focused on
ECDHE for IoT devices. The DTLS/TLS profile and other IETF
specifications very much focused on ECDHE and do not consider the use of
DHE.

Ciao
Hannes

On 03/29/2016 03:11 PM, Sean Turner wrote:
> All,
> 
> To make sure we’ve got a clear way forward coming out of our BA
> sessions, we need to make sure there’s consensus on a couple of
> outstanding issues.  So...
> 
> There also seems to be (rougher) consensus not to support 0-RTT via
> DHE  (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only
> 0-RTT mode as PSK. The security properties of PSK-based 0-RTT and
> DHE-based 0-RTT are almost identical, but 0-RTT PSK has better
> performance properties and is simpler to specify and implement. Note
> that this does not permanently preclude supporting DHE-based 0-RTT in
> a future extension, but it would not be in the initial TLS 1.3 RFC.
> 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Mar 2016 08:05:20 -0700

Hannes,

No, the proposal is to remove both EC and non-EC DHE 0-RTT profiles.

The only way to do 0-RTT would be with a PSK (in both PSK and PSK-(EC)DHE
modes).
However, this would include PSKs established via a previous session, i.e.,
resumption-PSK.

-Ekr

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 31 Mar 2016 17:33:52 +0200

Hi Ekr,

On 03/31/2016 05:05 PM, Eric Rescorla wrote:
> The only way to do 0-RTT would be with a PSK (in both PSK and
> PSK-(EC)DHE modes).

I see. This is, of course, a bit unfortunate.

> However, this would include PSKs established via a previous session,
> i.e., resumption-PSK.

Only established in previous sessions or also distributed out-of-band
(as it would be done with PSKs normally). The way you phrased it sounds
like you want to exclude the out-of-band case and I wonder why.

Ciao
Hannes

> 
> -Ekr
> 
> 
> On Thu, Mar 31, 2016 at 5:20 AM, Hannes Tschofenig
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Sean,
> 
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Mar 2016 09:26:47 -0700

> I see. This is, of course, a bit unfortunate.

Can you expand on why? The general sense of the discussion was that they
offered similar properties.

> like you want to exclude the out-of-band case and I wonder why.

No, the out-of-band case is fine.

-Ekr

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 31 Mar 2016 19:18:42 +0200

Hi Ekr,

> offered similar properties.

The PSK-ECDHE mode is less useful for the IoT space because you get the
overhead of the public key crypto without actually most of the benefits.
If you already go that step then I would recommend to use raw public
keys instead.

But since you clarified the question about the use of out-of-band
provisioned PSKs below it just means that someone using public key-based
authentication will have more roundtrips (compared to the PSK case).

> No, the out-of-band case is fine.
Ok. Good.

Ciao
Hannes

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 31 Mar 2016 23:39:42 -0400

On Tue, Mar 29, 2016 at 9:11 AM, Sean Turner <[email-masked]> wrote:

> almost identical,

​I am not offering an opinion about what the WG should decide regarding
keeping
DHE-based 0-RTT in the base TLS 1.3 document, but just wanted to note that
the
above claim "The security properties of PSK-based 0-RTT and DHE-based 0-RTT
are
almost identical" is not quite right (nothing I say here is new, I just felt
that I had to "object" to this statement as written).

There are some significant differences - in some cases even "fundamental
differences" - between keeping secret state (in the PSK case) and keeping
non-secret state (in the DHE case) or even not keeping state at all (in the
DHE case) and retrieving the server key g^s from some external source (with
integrity but not secrecy).  In addition, using DHE 0-RTT would require the
client to send a key share g^x leading to a PFS 1-RTT exchange while with
PSK
it may be "tempting" to omit PFS.  Moreover,  if the server's configuration
key g^s is refreshed often (say each 5 minutes) then the g^xs key used by
the
client to protect its 0-RTT data already has some good level of forward
secrecy (the attacker has a 5 minute window to find s and after that forward
security is guaranteed).  The latter point touches on an important aspect
which is the key management complexity of ticket encryption/decryption keys
(as needed in the PSK case) vs managing secret DH key s (in the DHE case).
I am not sure what would be done better (more secure) in practice.

But really it seems that the discussion boils down to identifying cases of
enough interest where avoiding the original 1-RTT trip for establishing a
session ticket is important. I am puzzled by the fact that the Google team
seems ok with something that essentially voids the main feature and design
basis of of QUIC.

Hugo​

​​

> but 0-RTT PSK has better performance properties and is simpler to specify
> and implement. Note that this does not permanently preclude supporting
> DHE-based 0-RTT in a future extension, but it would not be in the initial
> TLS 1.3 RFC.
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Mar 2016 20:49:07 -0700

On Thu, Mar 31, 2016 at 8:39 PM, Hugo Krawczyk <[email-masked]>
wrote:

> above claim "The security properties of PSK-based 0-RTT and DHE-based
> 0-RTT are
> it may be "tempting" to omit PFS.
>

The current plan of record is to allow the server to specify which cipher
suites it is
willing to accept, so it could refuse this

Moreover,  if the server's configuration
> I am not sure what would be done better (more secure) in practice.

Can you expand on the difference here? Say that the server implements
tickets
by storing a DH private key and then encrypting the ticket under the
corresponding
public key. How does this provide different PFS properties?

-Ekr