Re: [TLS] Allow KeyShare in HelloRetry if not advertised in ClientHello?

On Tue, Mar 7, 2017 at 9:44 AM, Roelof Du Toit <Roelof_Dutoit@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.

-Ekr

>
> Roelof du Toit
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>