Re: [TLS] Pull request for 1RTT Handshake

[Eric Rescorla <[e-mail]>]

On Thu, Jul 3, 2014 at 9:41 PM, Watson Ladd <[e-mail]> wrote:

> On Thu, Jul 3, 2014 at 9:00 PM, Eric Rescorla <[e-mail]> wrote:
>
> Why send two messages when one will do? In particular the server can
> send a Server Key Exchange,
> and a Certificate, CertificateVerify message in response to the Client
> Hello.
>

I assume you intend the ServerHello here as well, since you need that for
the
cipher suite, etc.?



> Once the client receives this, it's ready to send data after its CKE
> and such messages.
>
> Restarting the protocol the way we have now introduces another round trip.
>

Ah, I understand what you are suggesting.

Certainly something like this is possible, but the general sense of the
discussion at the Interim was that people wanted the "wrong group"
handshake to look like a missed guess/correction followed by the "right
group" handshake, in the interest of simplicity. Note also that if we
have a relatively small number of groups (which seems like a good idea
in any case) then the vast majority of handshakes can complete in 1-RTT
because the client guesses right (e.g., they send P256 and 25519 and
the server supports one or both.)

Another difficulty is that it in the flow you are suggesting, you don't
protect
the server's first flight, which includes:

- The server's extensions response (and request if we add DKG/Ritter's
   'type B extensions').

- The server's certificate (relevant if using SNI encryption and for
   passive protection for P2P applications).

In some cases, an attacker can elicit these, so protection is just
passive, and in others he cannot, in which case protection is also
active.

Best,
-Ekr