Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Describe interaction between QUIC and TLS regarding saved 0-RTT state #2947

Merged
merged 3 commits into from
Oct 15, 2019
Merged

Describe interaction between QUIC and TLS regarding saved 0-RTT state #2947

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
bee9501
Describe interaction between QUIC and TLS regarding saved 0-RTT state
nharper Aug 1, 2019
c09d599
Apply suggestions from code review
nharper Aug 23, 2019
635ab6c
Reword sentence about storing state in session ticket
nharper Oct 11, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
40 changes: 32 additions & 8 deletions draft-ietf-quic-tls.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -279,13 +279,14 @@ components:
protection being called out specially.

~~~
+------------+ +------------+
| |<- Handshake Messages ->| |
| |<---- 0-RTT Keys -------| |
| |<--- Handshake Keys-----| |
| QUIC |<---- 1-RTT Keys -------| TLS |
| |<--- Handshake Done ----| |
+------------+ +------------+
+------------+ +------------+
| |<---- Handshake Messages ----->| |
| |<- Validate 0-RTT parameters ->| |
| |<--------- 0-RTT Keys ---------| |
| QUIC |<------- Handshake Keys -------| TLS |
| |<--------- 1-RTT Keys ---------| |
| |<------- Handshake Done -------| |
+------------+ +------------+
| ^
| Protect | Protected
v | Packet
Expand Down Expand Up @@ -359,10 +360,12 @@ levels fit into the handshake process.

## Interface to TLS

As shown in {{schematic}}, the interface from QUIC to TLS consists of three
As shown in {{schematic}}, the interface from QUIC to TLS consists of four
primary functions:

- Sending and receiving handshake messages
- Processing stored transport and application state from a resumed session
and determining if it is valid to accept early data
- Rekeying (both transmit and receive)
- Handshake state updates

Expand Down Expand Up @@ -644,6 +647,27 @@ A client MAY attempt to send 0-RTT again if it receives a Retry or Version
Negotiation packet. These packets do not signify rejection of 0-RTT.


## Validating 0-RTT Configuration

When a server receives a ClientHello with the "early_data" extension, it has to
decide whether to accept or reject early data from the client. Some of this
decision is made by the TLS stack (e.g., checking that the cipher suite being
resumed was included in the ClientHello; see Section 4.2.10 of {{!TLS13}}). Even
when the TLS stack has no reason to reject early data, the QUIC stack or the
application protocol using QUIC might reject early data because the
configuration of the transport or application associated with the resumed
session is not compatible with the server's current configuration.

QUIC requires additional transport state to be associated with a 0-RTT session
ticket. One common way to implement this is using stateless session tickets and
storing this state in the session ticket. Application protocols that use QUIC
might have similar requirements regarding associating or storing state. This
associated state is used for deciding whether early data must be rejected. For
example, HTTP/3 ({{QUIC-HTTP}}) settings determine how early data from the
client is interpreted. Other applications using QUIC could have different
requirements for determining whether to accept or reject early data.


## HelloRetryRequest

In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of {{!TLS13}})
Expand Down