On Thu, Dec 22, 2016 at 2:28 PM, Joseph Salowey <j...@salowey.net> 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 <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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
