Hi Xuelei, As per RFC 4279 also, both the client and server are supposed to have a set of “Identity – key” pair on either sides. The “ServerKeyExchange.psk_identity_hint” only helps the client in choosing an “identity-key” pair from a list of several “identity-key pairs” the client may have.
In TLS 1.3, instead of the ServerKeyExchange.psk_identity_hint, client sends its list of identities in the client hello itself through PreSharedKey Extension and server chooses one from it and replies in the PreSharedKey Extension. Now, instead of traditional session resumption, this logic will be used which basically has the same abbreviated handshake. So, essentially, TLS 1.2 to TLS 1.3 transition for the above scenario should be viewed as below: (a) In case of PSK, instead of Client guessing and using an Identity based on PSK Identity Hint, both client and server negotiate which identity to use in the hello messages itself. (b) ServerKeyExchange.psk_identity_hint can be obsoleted removed when you transition from 1.2 to 1.3. In my opinion, this makes the PSK based handshake a lot more simpler and easier to use. Could you elaborate on your scenario based on which you say the transition from TLS 1.2 to TLS 1.3 for PSK will be difficult? Regards, Jay *************************************************************************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! *************************************************************************************** From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Xuelei Fan Sent: 27 November 2015 17:29 To: tls@ietf.org Subject: [TLS] TLS 1.3 and RFC 4279, Pre-Shared Key Ciphersuites 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
