[TLS] Initial draft of DH-based key exchange

[Eric Rescorla <[e-mail]>]

Folks,

At the interim discussed transitioning to a DH-based handshake (rather
than a signature-based one) like that proposed by Hugo Krawczyk and
Hoeteck Wee. The major rationale for this change is that any 0-RTT
mode is inherently DH-based and so if we make that our basic mode,
then we can simplify the protocol logic and key derivation model. This
model also allows us to pull in PSK modes under the same basic
structure.

However, in the near term it's clear that servers will continue to
have RSA and ECDSA certificates rather than (EC)DH certificates, so
we need some way to reuse those credentials. The two major options are:

- An offline signature of the server's DH share.
- An online signature of the server's DH share that's tied to the
  handshake in some way.

The WG sentiment was generally favorable to exploring this avenue but
there was also airly strong WG sentiment that we didn't presently want
to do an offline signatures. This leaves with a model in which the
client initially learns the server's semi-static DH share through
an online-signed 1-RTT handshake but then can cache it for use with
future connections.

As an outcome of the interim, I was asked to write up an initial draft
of what this would all look like and post it to the list. You can find
such a draft at:

Git branch:
https://github.com/ekr/tls13-spec/tree/WIP_dh_based

Text file:
https://github.com/ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tls13-dh-based.txt

HTML diff:
https://github.com/ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tls13-dh-based-diff.html


Please note that this is a very rough draft and no doubt contains
a number of major errors (and certainly has seen no security review).
Please point these out to me if you find them, especially if they
impede understanding. Assuming that people are happy with this
general direction, I will clean it up and turn it into a PR.

A number of other notes:

- There is generally not support here for 0-RTT. I am developing that
  on a separate branch (based on that branch) and will be cleaning it
  up and posting it in the next few days. You will, however, probably
  notice some hooks for 0-RTT that don't do anything yet.

- In Section 7.3.7 there is a discussion about using the same DH share
  for the semi-static and epehemeral server keys. This is an important
  part of getting performance comparable between the 1-RTT mode and
  the current 1-RTT mode. We discussed this extensively at the interim
  and I believe that Hugo and Hoeteck consider this safe, but any
  information to the contrary would be very useful at this point.

- The key schedule in Section 8.1 is probably going to change, but
  that shouldn't impede understanding.

- During the interim we also discussed moving to HKDF. This branch
  includes a draft version of that change as well as using separate
  HKDF invocations to generate each traffic key.

As usual comments welcome; I look forward to discussing this in Dallas.

-Ekr