On Thu, Nov 26, 2015 at 3:03 PM, Dave Garrett <[email protected]> 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 >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
