[TLS] Pull request for 1RTT Handshake

[Eric Rescorla <[e-mail]>]

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.