Thank you Eric From: Eric Rescorla <e...@rtfm.com> Date: Tuesday, March 7, 2017 at 2:50 PM To: Roelof Du Toit <roelof_dut...@symantec.com> Cc: David Benjamin <david...@chromium.org>, "tls@ietf.org" <tls@ietf.org> Subject: Re: [TLS] Allow KeyShare in HelloRetry if not advertised in ClientHello?
This appears in https://tlswg.github.io/tls13-spec/#resumption-and-psk "As the server is authenticating via a PSK, it does not send a Certificate or a CertificateVerify message. When a client offers resumption via PSK, it SHOULD also supply a “key_share” extension to the server to allow the server to decline resumption and fall back to a full handshake, if needed. " -Ekr On Tue, Mar 7, 2017 at 11:35 AM, Roelof Du Toit <roelof_dut...@symantec.com<mailto:roelof_dut...@symantec.com>> wrote: Thank you. The following text in 4.2.7 prompted my scenario: "" A server which receives an “early_data” extension MUST behave in one of three ways:" .. - Request that the client send another ClientHello by responding with a HelloRetryRequest. A client MUST NOT include the “early_data” extension in its followup ClientHello. "" My conclusion from your replies is that the burden is on the client to avoid the scenario by including an empty key_share (with corresponding sigalgs and supported_groups) when sending early_data with psk_ke mode (vs psk_dhe_ke). It might be worth warning implementers about that in the spec. --Roelof From: David Benjamin <david...@chromium.org<mailto:david...@chromium.org>> Date: Tuesday, March 7, 2017 at 1:05 PM To: Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>>, Roelof Du Toit <roelof_dut...@symantec.com<mailto:roelof_dut...@symantec.com>> Cc: "tls@ietf.org<mailto:tls@ietf.org>" <tls@ietf.org<mailto:tls@ietf.org>> Subject: Re: [TLS] Allow KeyShare in HelloRetry if not advertised in ClientHello? On Tue, Mar 7, 2017 at 12:49 PM Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>> wrote: On Tue, Mar 7, 2017 at 9:44 AM, Roelof Du Toit <roelof_dut...@symantec.com<mailto:roelof_dut...@symantec.com>> wrote: All, The current language in https://tlswg.github.io/tls13-spec/#rfc.section.4.1.4 states: As with ServerHello, a HelloRetryRequest MUST NOT contain any extensions that were not first offered by the client in its ClientHello, with the exception of optionally the “cookie” (see Section 4.2.2<https://tlswg.github.io/tls13-spec/#cookie>) extension. I am analyzing the following message flow: ClientHello + early_data + psk_key_exchange_modes = psk_ke + pre_shared_key ---------> (Early Data) ---------> *reject* <--------- HelloRetryRequest (not allowed to add key_share) ClientHello + supported_groups + key_share ---------> *not supported* At that point in the flow the server is not allowed to send another HelloRetryRequest. To avoid that the client would need some hints in the HelloRetryRequest. Would it be possible to allow an exception to send key_share and/or supported_groups in a HelloRetryRequest if not offered in ClientHello? I would prefer not. If the client is willing to do DH, it should offer KeyShare in its initial ClientHello. In particular, per 4.2.5: "Clients MAY send an empty client_shares vector in order to request group selection from the server at the cost of an additional round trip." David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
