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

From: Russ Housley <[email-masked]>
Date: Thu, 22 Dec 2016 16:54:18 -0500

I want to make sure that it is possible to mix PSK with (EC)DH as a protection against the discovery of a quantum computer.  I recognize that the WG does not want to tackle this topic in the base specification; however, the following text in Section 4.1.1 makes this difficult to do so in a companion document:

>    The server indicates its selected parameters in the ServerHello as
>    follows:
>
>    -  If PSK is being used then the server will send a "pre_shared_key"
>       extension indicating the selected key.
>
>    -  If PSK is not being used, then (EC)DHE and certificate-based
>       authentication are always used.
>
>    -  When (EC)DHE is in use, the server will also provide a "key_share"
>       extension.
>
>    -  When authenticating via a certificate (i.e., when a PSK is not in
>       use), the server will send the Certificate (Section 4.4.1) and
>       CertificateVerify (Section 4.4.2) messages.

An Internal PSK offers no protection against the discovery of a quantum computer.  I assume that an attacker can save the handshake that established the Internal PSK, and then at some future date use the quantum computer to discover the Internal PSK.  Therefore, protection against the discovery of a quantum computer is only concerned with External PSK.

I would like for the specification to permit normal certificate authentication when someone is using an External PSK.  I am guessing that the granularity of the name associated with the External PSK to be pretty broad.  If this guess is correct, it would be appropriate for the name in the certificate to be further restrict the one associated with the External PSK.  Maybe the External PSK is associated with example.com, and then the certificate that includes www.example.com would be acceptable acceptable.  Then, I would expect any Internal PSK that is generated after such an authentication would be associated with the more granular certificate name.

Maybe it is as simple as reorganizing these bullets like this:

   - When only PSK is being used, …

   - When only (EC)DHE is being used, …

   - When PSK and (EC)DHE are both being used, …

If others agree with this direction, I am willing to propose some text.

Happy holidays,
   Russ

---

From: David Benjamin <[email-masked]>
Date: Thu, 22 Dec 2016 22:12:25 +0000

It's possible I'm misunderstanding your message here (I'm a little confused
by the mention of combining normal certificate authentication with an
external PSK), but TLS 1.3 already allows doing both PSK and (EC)DH. That's
the psk_dhe_ke mode, rather than the psk_ke mode. It's signaled by the
server by sending both pre_shared_key and key_share extensions. Perhaps the
wording should be a bit clearer.

Our stack does not even implement psk_ke. It always requires an (EC)DH
operation in a TLS 1.3 handshake, whether using PSK or certificates.

David

On Thu, Dec 22, 2016 at 4:54 PM Russ Housley <[email-masked]> wrote:

> I want to make sure that it is possible to mix PSK with (EC)DH as a
> protection against the discovery of a quantum computer.  I recognize that
> the WG does not want to tackle this topic in the base specification;
> however, the following text in Section 4.1.1 makes this difficult to do so
> in a companion document:
>
> An Internal PSK offers no protection against the discovery of a quantum
> computer.  I assume that an attacker can save the handshake that
> established the Internal PSK, and then at some future date use the quantum
> computer to discover the Internal PSK.  Therefore, protection against the
> discovery of a quantum computer is only concerned with External PSK.
>
> I would like for the specification to permit normal certificate
> authentication when someone is using an External PSK.  I am guessing that
> the granularity of the name associated with the External PSK to be pretty
> broad.  If this guess is correct, it would be appropriate for the name in
> the certificate to be further restrict the one associated with the External
> PSK.  Maybe the External PSK is associated with example.com, and then the
> certificate that includes www.example.com would be acceptable
> acceptable.  Then, I would expect any Internal PSK that is generated after
> such an authentication would be associated with the more granular
> certificate name.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 22 Dec 2016 14:28:40 -0800

Does you implementation allow a PSK to be used along with certificate based
authentication?

On Thu, Dec 22, 2016 at 2:12 PM, David Benjamin <[email-masked]>
wrote:

> It's possible I'm misunderstanding your message here (I'm a little
> confused by the mention of combining normal certificate authentication with
> an external PSK), but TLS 1.3 already allows doing both PSK and (EC)DH.
> That's the psk_dhe_ke mode, rather than the psk_ke mode. It's signaled by
> the server by sending both pre_shared_key and key_share extensions. Perhaps
> the wording should be a bit clearer.
>
>> PSK.  Maybe the External PSK is associated with example.com, and then
>> the certificate that includes www.example.com would be acceptable

---

From: Russ Housley <[email-masked]>
Date: Thu, 22 Dec 2016 17:29:45 -0500

David:

Yes, it does allow both, but the authentication is unclear when both are in play. The last bullet implies that certificate authentication only comes into play when there is no PSK.  So, if there is a PSK, the identity associated with it seems to trump whatever is in the certificate.

As I explained below, I’d like the identity associate with the External PSK and the identity in the certificate to both have a role.

Russ

On Dec 22, 2016, at 5:12 PM, David Benjamin <[email-masked]> wrote:

> It's possible I'm misunderstanding your message here (I'm a little confused by the mention of combining normal certificate authentication with an external PSK), but TLS 1.3 already allows doing both PSK and (EC)DH. That's the psk_dhe_ke mode, rather than the psk_ke mode. It's signaled by the server by sending both pre_shared_key and key_share extensions. Perhaps the wording should be a bit clearer.
> 
> Our stack does not even implement psk_ke. It always requires an (EC)DH operation in a TLS 1.3 handshake, whether using PSK or certificates.
> 
> David
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Dec 2016 14:45:22 -0800

On Thu, Dec 22, 2016 at 2:28 PM, Joseph Salowey <[email-masked]> wrote:

> Does you implementation allow a PSK to be used along with certificate
> based authentication?
>

There is presently no way to negotiate this in TLS 1.3. I have been
assuming that if we decide we
want this we would add a psk_auth_mode extension to parallel psk_ke_mode.
The sense of a number
of us is that there are enough complications with adding this feature
(consider what happens if the
server provides a different set of SANs....) that we should add it later.

-Ekr