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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 3 Jan 2017 19:02:38 -0600

I also had the sense that ekr noted that we didn't want to do this in
the core spec.
So, could you point me more clearly at what you would want to change in
the core spec that would allow doing the thing you want to see done in a
future document?  (Is it just removing "i.e., when a PSK is not in use"?)

-Ben

On 12/22/2016 04:29 PM, Russ Housley wrote:
> 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]
> <mailto:[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
>>
>> On Thu, Dec 22, 2016 at 4:54 PM Russ Housley <[email-masked]
>> <mailto:[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:
>>
>>     >    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
>>     <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_&d=DwMF-g&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=L7igTlV6YOIfY5Lb--b56L_kVzagQDYBba0h3CuE2Ug&s=Qh9_NqRvx6gQ7yd7xUbh7ty4wNEZb4WXWig2yeB15yU&e=>,
>>     and then the certificate that includes www.example.com
>>     <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.example.com_&d=DwMF-g&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=L7igTlV6YOIfY5Lb--b56L_kVzagQDYBba0h3CuE2Ug&s=hXFSjfgYGwtp4L2BKSOF67C4qzFaN9yX8A0HamQLdqY&e=>
>>     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
>>     _______________________________________________
>>     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=DwMF-g&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=L7igTlV6YOIfY5Lb--b56L_kVzagQDYBba0h3CuE2Ug&s=thMCyk6nvtg9KMys9ccc4NuxXMYd-v6zxVgD6rShHY0&e=>
>>
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Jan 2017 13:36:42 +1100

On 4 January 2017 at 12:02, Benjamin Kaduk <[email-masked]> wrote:
> I also had the sense that ekr noted that we didn't want to do this in the
> core spec.
> So, could you point me more clearly at what you would want to change in the
> core spec that would allow doing the thing you want to see done in a future
> document?  (Is it just removing "i.e., when a PSK is not in use"?)

I for one am interested in having a mode that allows for PSK+cert, but
it's hard to reason through.  It falls into the same bucket as
additive *server* authentication, which has the same inherent
problems.  Foremost being a solid analysis.

Mechanically, it is fairly simple to add as an extension.  That makes
me confident that we can do this later.

---

From: Russ Housley <[email-masked]>
Date: Wed, 4 Jan 2017 16:17:07 -0500

Ben:

> I also had the sense that ekr noted that we didn't want to do this in the core spec.
> So, could you point me more clearly at what you would want to change in the core spec that would allow doing the thing you want to see done in a future document?  (Is it just removing "i.e., when a PSK is not in use"?)
> 

I am not looking to put the details in the core spec.  I think I said that in my first posting.  However, I do want to ensure that the identity associated with the external PSK and the certificate are both considered.  There needs to be a hook in the core spec for that to happen.

I quotes the part of the core spec that seems to say otherwise.

>>> 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:
>>> 
>>> >    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"
>>> >    -  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

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 4 Jan 2017 16:23:20 -0500

> me confident that we can do this later.

Mee too.  At this point, the spec calls for the identity to come from the PSK or the certificate.  I think there needs to be a hook in the document for the identity to come from a combination of the PSK and the certificate.  I recognize this is a forward pointer to stuff that is not yet sorted out.

Russ

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 4 Jan 2017 19:33:30 -0600

Hi Russ,

On 01/04/2017 03:17 PM, Russ Housley wrote:
>> So, could you point me more clearly at what you would want to change
>> in the core spec that would allow doing the thing you want to see
>> done in a future document?  (Is it just removing "i.e., when a PSK is
>> not in use"?)
>>
>
> I am not looking to put the details in the core spec.  I think I said
> that in my first posting.  However, I do want to ensure that the
> identity associated with the external PSK and the certificate are both
> considered.  There needs to be a hook in the core spec for that to happen.
>

I understand that.

> I quotes the part of the core spec that seems to say otherwise.

What I don't understand is exactly which part or parts in combination of
the quoted text are saying otherwise, in your reading of it.  I offered
a potential part of the quoted text which might be leading you to that
interpretation (the "i.e., when a PSK is not in use" clause), and you
did not confirm or deny my guess.  So, I still don't understand what
seems problematic to you about the existing text -- to me, it says that
certain things must be done if certain other things are or are not done,
but does not seem to preclude certain things being done and certain
other things also being done. Maybe you could propose a patch that
provides the hook that you would like to see, so that I can understand
the issue with the current text?

-Ben

>>>>     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
>>>>     base specification; however, the following text in Section
>>>>     4.1.1 makes this difficult to do so in a companion document:
>>>>