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 <david...@chromium.org>
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 <hous...@vigilsec.com> 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
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to