Hi, In the draft spec of TLS 1.3, ServerKeyExchange and ClientKeyExchange get removed, and key_share extension applies to non-PSK cipher suites only. As RFC 4279 need ServerKeyExchange and ClientKeyExchange messages, I think TLS 1.3 updates or obsoletes RFC 4279.
Per the draft spec of TLS 1.3, if no suitable identity is provided in pre-shared key extension, the server MUST NOT negotiate a PSK cipher suite. The question comes to me: where the suitable identity comes from? The identity can be acquired by out-of-band approach, or the server NewSessionTicket message. If no out-of-band approach in some circumstances, the server NewSessionTicket message would be the only way to create the identity. The scenarios of using pre-shared key may look like: 1. establish a fresh connection, server sends the NewSessionTicket to indicate it supports session resumption and provide the psk_identity. 2. if client wants a session resumption, subsequent handshaking will use pre_shared key extension with the server provided psk_identity. Looks like PSK applies to session resume only in TLS 1.3, and cannot be used for fresh (initial) handshaking any more, unless out-of-band approach is used to define the identities. I have no experience on PSK, but looks like that it is not A minimal effort for PSK deployments to upgrade from TLS 1.2 to TLS 1.3, if ServerKeyExchange.psk_identity_hint is used previously. It would be nice to consider and specify the impact on RFC 4279 in TLS 1.3 protocols. Regards, Xuelei
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
