Subject: [TLS] Pull request for 1RTT Handshake

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 Jul 2014 07:54:00 -0700

I've just put up a pull request that makes the first cut changes from
the consensus from Denver for 1-RTT handshake without SNI
protection. As we discussed, I'm leaving the door open for SNI
protection, but since these are separable work items, and this is
already a fairly signficant change I wanted to get the 1-RTT stuff
down first.

The PR can be found at:

  https://github.com/tlswg/tls13-spec/pull/52

It's still kind of rough and there are a bunch of open issues (and
most likely several mistakes) but I think it's clear what direction
it's going in.

I wanted to explicitly called out some known open issues in the draft,
both so I can get feedback/discussion on these and so that people know
they haven't been forgotten:

- Based on the mailing list and interim discussion and a bunch of
  private conversations, I wrote this up as requiring named DHE groups
  (and assuming we will want named ECDHE groups). This makes things
  quite a bit simpler and seemed like a good idea anyway. I recognize
  that I'm a bit ahead of the list consensus here, but my sense is
  that this was the emerging consensus.  If there are major objections
  to this change, I can rework things otherwise, but I believe it will
  make things more confusing.

- I have partly removed dh_rsa and dh_dss because they get in the way
  of having a common handshake pattern and nobody seemed to want
  them. Assuming nobody screams I will do a separate PR to remove them
  entirely.

- We need to take care that we don't introduce a downgrade issue in
  the 2-RTT flow (Figure 2) where the server tells the client he has
  sent an incorrect CKE. There are some open issues noted in the draft
  about how to do this exactly. Comments welcome.

- MT convinced me that the client should be able to make multiple
  ClientKeyExchange offers for different parameter sets, so I did
  that.

- The EarlyData mechanism is a bit overgeneral as opposed to an
  explicit ClientKeyExchange extension, but it seems like it's going
  to be useful when we do SNI encryption and 0-RTT.

- I haven't assumed we are going to incorporate ECDHE, but that
  seems like it's likely coming. Similarly, I expect to incorporate
  the triple handshake fix separately.

- I haven't added any support for the server-offered extensions
  that were proposed in Denver. That seems separable.

I intend to merge this into the draft on Friday. As should be clear
from the draft and the comments above, there are still open issues to
resolve, so even when it's merged in some of this is obviously
provisional. With that said, if there's stuff that looks clearly wrong
or there is an open issue that isn't properly identified, please let
me know.

Thanks,
-Ekr

P.S. Thanks to all the people who helped with earlier versions of
this, in particular Wan-Teh Chang Daniel, Kahn Gillmor, Andy
Lutomirski, Andrei Popov, Tom Ritter, Rich Salz, and Martin
Thomson.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 3 Jul 2014 19:29:12 -0700

>   ClientKeyExchange offers for different parameter sets, so I did

So I don't why a client would change their Client Hello in response to
a Server Hello, and hence
why there can be a downgrade.

The client says "here are my capabilities, and some early guesses as
to what you want to see"
If those guesses are incorrect, there is no need for another Hello:
the server already knows what
the client wants to tell it, and the client knows what the server would see.

There is no state machine issue, because the server knows if it got
the data or not, and
the client will know if the negotiated curve and suite were among the guesses.

Another misfeature is the Finished message ordering: it slows down one
side or another.
If we fix Triple Handshake the right way, it's safe to send data
before receiving the other
Finished message.

>   to be useful when we do SNI encryption and 0-RTT.

Are we ever going to be able to turn it off? Clients initially will
use only it for compatibility. Servers will develop bugs
because clients all use it. Lather, rinse, reiterate.

Sincerely,
Watson Ladd

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 Jul 2014 21:00:17 -0700

> the client will know if the negotiated curve and suite were among the

I'm not saying that the client should change it's ClientHello, but since
there
are two messages, it could in principle do so, right?

The draft currently requires that the client not do so, in S 7.4.1.2:

      When a client first connects to a server, it is required to send
      the ClientHello as its first message.  The client can also send a
      ClientHello in response to a HelloRequest or on its own initiative
      in order to renegotiate the security parameters in an existing
      connection.  Finally, the client will send a ClientHello when the
      server has responded to its ClientHello with a ServerHello that
      selects cryptographic parameters that don't match the client's
      ClientKeyExchange.  In that case, the client MUST send the same
      ClientHello (without modification) along with the new
      ClientKeyExchange.

Does that seem problematic to you?

> before receiving the other

I'm not following your analysis here as to why this slows things down:

1. The client can't safely send data before it receives the server's
Certificate and CertificateVerify, since that's the first thing that
authenticates the server. These messages are sent in the same flight as the
Finished, so will arrive at more or less the same time.

2. If the server doesn't want client authentication for the data, it can
send data as soon as it receives the client's first flight. If not, then it
needs to wait for the client's Certificate and CertificateVerify, which
again is sent with the client's Finished. [0]

Why does the Finished slow things down in this case? What am I
missing?

> because clients all use it. Lather, rinse, reiterate.

Obviously, that's a potential problem, but it also seems pretty clear
that any extra data has to go in an extension for compatibility.

Best,
-Ekr

[0] DKG points out that the rules might be relaxable if the
server wants authentication for the client's data but might be willing
to send some data, such as a banner message, without client
auth, but let's deal with that later.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 3 Jul 2014 21:41:56 -0700

> Does that seem problematic to you?

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.

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.

In fact, it might be worth ditching the current client psyc approach
in favor of this one: less complex,
backwards compatibility by signalling an extension, and gets client
authentication in one round trip also.

This of course assumes a minor change to the protocol's calculation of
keys, and makes 0-RTT more of a jump.

> Why does the Finished slow things down in this case? What am I

I was a bit confused about what exactly Finished protects, and why we
need to wait for it.

> that any extra data has to go in an extension for compatibility.

Have you read the hello-pading draft? Or heard people complain about
Java interop with things not RC4?
Vendors are not adequately testing their ability to deal with legal
but unused corners of the spec, and virtually none of them are doing
adversarial fuzzing.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 Jul 2014 22:27:52 -0700

> and a Certificate, CertificateVerify message in response to the Client

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

> 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

---

From: Watson Ladd <[email-masked]>
Date: Fri, 4 Jul 2014 20:30:49 -0700

> the server supports one or both.)

True: the client can take a guess.
>    passive protection for P2P applications).

Unless I'm missing something you aren't either: the Change Cipher Spec
would come before the Certificate and Certificate Verification to
protect these two. But yes, this does require guessing of server
parameters, so once we need to do that, might as well guess more.

(It seems a bit weird to me to design the protocol one feature request
at a time: that way lies Perl 6. Also, I don't recall having seen
'type B extensions': what was the rationale? How was the answer going
to come back?)

Sincerely,
Watson Ladd