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

[Eric Rescorla <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
> *Date: *Tuesday, March 7, 2017 at 1:05 PM
> *To: *Eric Rescorla <[e-mail]>, Roelof Du Toit <
> [e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *Re: [TLS] Allow KeyShare in HelloRetry if not advertised in
> ClientHello?
>
>
>
> On Tue, Mar 7, 2017 at 12:49 PM Eric Rescorla <[e-mail]> wrote:
>
> On Tue, Mar 7, 2017 at 9:44 AM, Roelof Du Toit <[e-mail]
> > 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
>