Yes. Theoretically, you do seem to have a point. But, I have so far not come across implementations making an effective usage of Identity Hint. So, I guess this should not be such a big problem.
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: Xuelei Fan [mailto:xuelei....@vimino.com] Sent: 27 November 2015 20:34 To: Jayaraghavendran k Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 and RFC 4279, Pre-Shared Key Ciphersuites It is a great idea to use PSK for session resumption. However, as the ServerKeyExchange.psk_identity_hint disappears in TLS 1.3, I was wondering, it may be not easy to make an upgrade for those PSK implementation that relies on ServerKeyExchange.psk_identity_hint. Considering the following initial handshaking example in TLS 1.2. 1. client requests a PSK cipher suite negotiation; 2. server responses with a hint in ServerKeyExchange.psk_identity_hint 3. client looks for the shared key with the hint in the local database/cache/remote service, etc. 4. client provides the shared key in ClientKeyExchange.psk_identity. Here ServerKeyExchange.psk_identity_hint is used as an index to find the shared key in client side. If moving to TLS 1.3, as there is no hint any more, application may need to reconstruct the scenarios above in order to follow the spec of TLS 1.3 and find a new approach to get the shared key. If the client and server are supposed to have a short set of known “Identity – key” pair on either sides between them, the reconstruction can be minimal. If the shared keys are unknown previously before the hint get known, the reconstruction would get complicated. Just guessing theoretically, I have no practical evidence for the case. Hopefully, no one use the case in practice. Regards, Xuelei On Fri, Nov 27, 2015 at 10:00 PM, Jayaraghavendran k <jayaraghavendra...@huawei.com<mailto:jayaraghavendra...@huawei.com>> wrote: 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<mailto:tls-boun...@ietf.org>] On Behalf Of Xuelei Fan Sent: 27 November 2015 17:29 To: tls@ietf.org<mailto: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
