I agree with David here. Specifically, I think. - The base specification should continue to forbid certificates in combination with PSK - We should at some point contemplate an extension that allows the use of certificates in combination with PSK - The base spec should be factored in such a way as to make that extension easy.
-Ekr On Thu, Feb 2, 2017 at 8:24 AM, David Benjamin <david...@chromium.org> wrote: > I think this is much clearer, except for one bullet point below: > > On Thu, Feb 2, 2017 at 10:22 AM Russ Housley <hous...@vigilsec.com> wrote: > >> [...] >> - If PSK and (EC)DH are being used together, then the server will: >> >> -- sends a "pre_shared_key" extension to indicate the selected >> key; >> >> -- provide a "key_share" extension; and >> >> -- send the Certificate (Section 4.4.1) and CertificateVerify >> (Section 4.4.2) messages. > > > This last bullet here contradicts what specification says elsewhere. From > 4.4.1: > > """ > The server MUST send a Certificate message whenever the agreed-upon key > exchange method uses certificates for authentication (this includes all key > exchange methods defined in this document except PSK). This message conveys > the endpoint’s certificate chain to the peer. > """ > > (Otherwise we defeat the point of resumption and lose PSK-based > identities.) > > Like MT, I am interested in a mode with both (right now we have a ticket > renewal cliff because only the initial handshake does an online signature), > but we'll need to work out the exact semantics. Going from one identity to > two identities, especially when one is added partway through the stream > (consider 0-RTT) has a lot of sharp edges. > > Since this can easily be added as an extension (and would need one anyway > for negotiation), I think it's better to do it as a later document, so we > don't delay what we've done already or rush in a combined mode without > considering all the details. The document would just say "when PSK and > fancy_new_extension are both negotiated, then the server will [...]". > Plenty of extensions have modified the handshake message flow. > > David > > _______________________________________________ > 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
