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
