On Tue, Mar 7, 2017 at 9:44 AM, Roelof Du Toit <[email protected]> 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. -Ekr > > Roelof du Toit > > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
