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
