tree 13b1e1a7e7c8054ffc7d5f6d16bc0d8e5cf29d09
parent 95dd54e57ff79f5440c424cbd34c781da14269e7
author David Benjamin <davidben@google.com> 1565904542 -0400
committer CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> 1566949301 +0000

Add initial support for 0-RTT with QUIC.

This adapts our existing API for QUIC, although I'm not entirely
convinced the shape of it fits as it does with TCP. Things that needed
to be changed:

- There is a slight ordering issue on the server with HRR and releasing
  the 0-RTT keys to QUIC.

- Remove EndOfEarlyData.

- At the early return point for the server, QUIC needs to have installed
  the client traffic secrets earlier.

- The maximum early data value is a constant in QUIC.

- QUIC never installs early secrets at the TLS level. (In particular,
  this avoids nuisances with do_send_second_client_hello's null cipher
  not updating the encryption level.)

- The read/write secrets for 0-RTT keys were mixed up.

As the QUIC tests are getting a bit unwieldy, I tidied them up a bit.
This CL does *not* handle the QUIC transport parameters or HTTP/3
server SETTINGS frame interactions with 0-RTT. That will be done in a
separate CL.

I suspect if we ever implement DTLS 1.3, we'll find ourselves wanting to
align some of the QUIC bits here with DTLS and perhaps refine the
handshake/transport abstractions a bit.

Bug: 221
Change-Id: I61f701d7241dbc99e5dbf57ae6c283e10b85b049
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37145
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>