Re: [TLS] Replacing HelloRetryRequest in TLS 1.3?

[Eric Rescorla <[e-mail]>]

On Thu, Nov 26, 2015 at 3:03 PM, Dave Garrett <[e-mail]>
wrote:

> HelloRetryRequest is annoying


I guess this is a matter of opinion.


The main thing that comes to mind would be to provide a way for a server to
> respond to a client with a ServerConfiguration, but not a hello, and put
> group support in there (maybe a whole supported_groups extension). Clients
> that don't provide the needed key would get a config and a fatal alert
> telling it that it needs to use a supported group from that config. The
> client could then retry as it does now or do 0-RTT with early data, which
> could cut an RTT out of the current flow. (This is similar to the QUIC way
> of doing things.)


The server could certainly tell the client what groups it supports, but
given
that the server already knows precisely what the client's capabilities are
at this point, there's no good reason why it shouldn't simply tell the
client
what to do. This matches the usual TLS negotiation model.

For obvious reasons, if the client is to send data in response to the
server's
first flight (as you suggest)  it's going to have to have an authenticated
public key.
However, that public key will need to be authenticated via a signature,
which
means carrying the server's cert, which means that we're encrypting much
less of the handshake. In addition, you either have to have a statically
signed
configuration (which we've already rejected for the general case) or the
server has to perform an online signature, which means that the server
has no defense against computational DoS attacks unless we introduce
yet another cookie mechanism.

For these reasons, I believe that the current design is superior.

-Ekr



>
> Dave
>