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.

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

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

Merged
merged 3 commits into from Oct 15, 2019
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
10 changes: 5 additions & 5 deletions draft-ietf-quic-tls.md
Expand Up @@ -364,8 +364,8 @@ 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 0-RTT capable session
ticket and determining if it is valid to accept early data on the connection
- 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 @@ -647,7 +647,7 @@ 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
## 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
Expand All @@ -664,8 +664,8 @@ 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 requiremenets
for determining whether ot accept or reject early data.
interpreted. Other applications using QUIC could have different requirements
for determining whether to accept or reject early data.


## HelloRetryRequest
Expand Down