Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

From: Russ Housley <[email-masked]>
Date: Fri, 24 Mar 2017 12:16:48 -0400

> I agree with David here. Specifically, I think.
> 
> - The base specification should continue to forbid certificates in combination with PSK
> - We should at some point contemplate an extension that allows the use of certificates in combination with PSK
> - The base spec should be factored in such a way as to make that extension easy.

While I agree that we do not want to delay the TLS 1.3 specification to sort this out; however, I do not think we have provided the hook to make this future extension easy.   Looking at the key schedule in -19, I think we can provide the hook without being disruptive.  My goal is to minimize the pain to implementing the extension in the future by putting a straightforward hook in today:

                 0
                 |
                 v
   PSK ->  HKDF-Extract = Early Secret
                 |
                 +-----> Derive-Secret(.,
                 |                     "external psk binder key" |
                 |                     "resumption psk binder key",
                 |                     "")
                 |                     = binder_key
                 |
                 +-----> Derive-Secret(., "client early traffic secret",
                 |                     ClientHello)
                 |                     = client_early_traffic_secret
                 |
                 +-----> Derive-Secret(., "early exporter master secret",
                 |                     ClientHello)
                 |                     = early_exporter_secret
                 v
           Derive-Secret(., "derived secret", "")
                 |
                 v
(EC)DHE -> HKDF-Extract = Handshake Secret
                 |
                 +-----> Derive-Secret(., "client handshake traffic secret",
                 |                     ClientHello...ServerHello)
                 |                     = client_handshake_traffic_secret
                 |
                 +-----> Derive-Secret(., "server handshake traffic secret",
                 |                     ClientHello...ServerHello)
                 |                     = server_handshake_traffic_secret
                 v
           Derive-Secret(., "derived secret", "")
                 |
                 v
ExtPSK OR 0 -> HKDF-Extract = Master Secret
                 |
                 +-----> Derive-Secret(., "client application traffic secret",
                 |                     ClientHello...Server Finished)
                 |                     = client_traffic_secret_0
                 |
                 +-----> Derive-Secret(., "server application traffic secret",
                 |                     ClientHello...Server Finished)
                 |                     = server_traffic_secret_0
                 |
                 +-----> Derive-Secret(., "exporter master secret",
                 |                     ClientHello...Server Finished)
                 |                     = exporter_secret
                 |
                 +-----> Derive-Secret(., "resumption master secret",
                                       ClientHello...Client Finished)
                                       = resumption_master_secret

The only change is "ExtPSK OR 0” in the HKDF-Extract for the Master Secret computation.

The Section 4.1.1 can call out this place for the future specification:

OLD:

   -  When authenticating via a certificate, the server will send the
      Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3)
      messages.  In TLS 1.3 as defined by this document, either a PSK or
      a certificate is always used, but not both.  Future documents may
      define how to use them together.

NEW:

   -  When authenticating via a certificate, the server will send the
      Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3)
      messages.  In TLS 1.3 as defined by this document, either a PSK or
      a certificate is always used, but not both.  So, the ExtPSK is not
      used in the key schedule (Section 7.1).  Future documents may
      define how to use them together and tell how the ExtPSK is
      handled in the key schedule.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Mar 2017 10:19:09 -0700

Why would the external PSK not just go into he PSK slot.

-Ekr

On Fri, Mar 24, 2017 at 9:16 AM, Russ Housley <[email-masked]> wrote:

> While I agree that we do not want to delay the TLS 1.3 specification to
> sort this out; however, I do not think we have provided the hook to make
> this future extension easy.   Looking at the key schedule in -19, I think
> we can provide the hook without being disruptive.  My goal is to minimize
> the pain to implementing the extension in the future by putting a
> straightforward hook in today:
>
>                  0
>                  |
>                  v

---

From: Jim Schaad <[email-masked]>
Date: Fri, 24 Mar 2017 22:14:51 -0500

EKR – I think that is the wrong answer because of the resume case.

However, I would expect that the external PSK would be appended or otherwise munge into the computed secret (assuming DH) and would be consumed as part of that processing.  No additional slot needed.

jim

From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Friday, March 24, 2017 12:19 PM
To: Russ Housley <[email-masked]>
Cc: IETF TLS <[email-masked]>
Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

-Ekr

                 0
                 |
                 v

OLD:

NEW:

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 25 Mar 2017 04:40:18 -0700

> EKR – I think that is the wrong answer because of the resume case.

Why? It seems like for Russ'a application, you would inject the static PSK
initially
and then it would be implicitly part of any resumption so no need to
reinject it
to obtain PQ safety.

-Ekr

However, I would expect that the external PSK would be appended or
> otherwise munge into the computed secret (assuming DH) and would be
> consumed as part of that processing.  No additional slot needed.
>
>
>
> jim
>
>
>
> *From:* TLS [mailto:[email-masked]] *On Behalf Of *Eric Rescorla
> *Sent:* Friday, March 24, 2017 12:19 PM
> *To:* Russ Housley <[email-masked]>
> *Cc:* IETF TLS <[email-masked]>
> *Subject:* Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3
>
>
>

---

From: Jim Schaad <[email-masked]>
Date: Sat, 25 Mar 2017 07:49:12 -0500

From: Eric Rescorla [mailto:[email-masked]] 
Sent: Saturday, March 25, 2017 6:40 AM
To: Jim Schaad <[email-masked]>
Cc: Russ Housley <[email-masked]>; IETF TLS <[email-masked]>
Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

On Fri, Mar 24, 2017 at 8:14 PM, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

Why? It seems like for Russ'a application, you would inject the static PSK initially

and then it would be implicitly part of any resumption so no need to reinject it

to obtain PQ safety.

It seems odd to me that you would want to use a different key agree algorithm when you are doing the initial negotiation as opposed to the resumption.   Depending on how the static PSK is specified, it might need to be restated for the resumption as well.

Jim

-Ekr

jim

From: TLS [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Eric Rescorla
Sent: Friday, March 24, 2017 12:19 PM
To: Russ Housley <[email-masked] <mailto:[email-masked]> >
Cc: IETF TLS <[email-masked] <mailto:[email-masked]> >
Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

-Ekr

                 0
                 |
                 v

OLD:

NEW:

Russ

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 25 Mar 2017 15:52:17 +0200

On Fri, Mar 24, 2017 at 12:16:48PM -0400, Russ Housley wrote:
> While I agree that we do not want to delay the TLS 1.3 specification
> to sort this out; however, I do not think we have provided the hook
> to make this future extension easy.   Looking at the key schedule in
> -19, I think we can provide the hook without being disruptive.  My
> goal is to minimize the pain to implementing the extension in the
> future by putting a straightforward hook in today:

Unless you have fairly good idea about how such extension would look
(especially security properties!), I think it is premature to specify
where the key will go (if it doesn't go there, you got problems).

At least from what I know about my implementation, adding new keys
to be injected in present spots is easy (after one has computed
the value, it is one method call to inject it). Actually changing
what keys are derived from each stage or creating new stages is of
course expensive.

Currently, there are three stages in key schedule.
- 0-RTT (Binders, 0-RTT keys and 0-RTT exporters).
- Handshake (handshake keys, finished)
- Application (application keys, exporters and dynamic PSKs).

In comparision, new handshake message would be far more expensive
code-wise, even if I could piggyback main handshake states like with
CertificateRequest. And something that actually changes the main
state machine would be far more expensive still.

And extension specs are only really bound by TLS offer-answer
rules. The rest is matter of how difficult the extensions are
actually to implement, and how much security problems they
have...

-Ilari