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

[Jim Schaad <[e-mail]>]

 

 

From: Eric Rescorla [mailto:[e-mail]] 
Sent: Saturday, March 25, 2017 6:40 AM
To: Jim Schaad <[e-mail]>
Cc: Russ Housley <[e-mail]>; IETF TLS <[e-mail]>
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 <[e-mail] <mailto:[e-mail]> > wrote:

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.

 

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

 

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

 

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

 

-Ekr

 

 

On Fri, Mar 24, 2017 at 9:16 AM, Russ Housley <[e-mail] <mailto:[e-mail]> > wrote:


> 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