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
