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

[Eric Rescorla <[e-mail]>]

On Thu, Dec 22, 2016 at 2:28 PM, Joseph Salowey <[e-mail]> 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


> On Thu, Dec 22, 2016 at 2:12 PM, David Benjamin <[e-mail]>
> 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 <[e-mail]>
>> 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, 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
>>> _______________________________________________
>>> TLS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>