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> 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> > *Date: *Tuesday, March 7, 2017 at 1:05 PM > *To: *Eric Rescorla <e...@rtfm.com>, Roelof Du Toit < > roelof_dut...@symantec.com> > *Cc: *"tls@ietf.org" <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> wrote: > > On Tue, Mar 7, 2017 at 9:44 AM, Roelof Du Toit <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
