From bee95016e3be73001dba5efdae015312a4659a2c Mon Sep 17 00:00:00 2001 From: Nick Harper Date: Thu, 1 Aug 2019 11:58:29 -0700 Subject: [PATCH 1/3] Describe interaction between QUIC and TLS regarding saved 0-RTT state This PR describes how a TLS stack needs to cooperate with a QUIC stack when making the decision whether or not to accept early data. The purpose of this change is so that implementors working on the TLS layer of QUIC are aware that other layers impact decisions traditionally made at the TLS layer. --- draft-ietf-quic-tls.md | 40 ++++++++++++++++++++++++++++++++-------- 1 file changed, 32 insertions(+), 8 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 82c2d515fe..2f51bfebca 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -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 @@ -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 0-RTT capable session + ticket and determining if it is valid to accept early data on the connection - Rekeying (both transmit and receive) - Handshake state updates @@ -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. If stateless session tickets are used, this information must be stored +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. + + ## HelloRetryRequest In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of {{!TLS13}}) From c09d599bade53a8faea33a264c21d1a57de2d179 Mon Sep 17 00:00:00 2001 From: Nick Harper Date: Thu, 22 Aug 2019 22:50:41 -0700 Subject: [PATCH 2/3] Apply suggestions from code review Co-Authored-By: Martin Thomson --- draft-ietf-quic-tls.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 2f51bfebca..bf43d40f62 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -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 @@ -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 @@ -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 From 635ab6cee20af55c617202c8301b5b5179c31744 Mon Sep 17 00:00:00 2001 From: Nick Harper Date: Fri, 11 Oct 2019 13:12:25 -0700 Subject: [PATCH 3/3] Reword sentence about storing state in session ticket --- draft-ietf-quic-tls.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index bf43d40f62..41b0811789 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -659,13 +659,13 @@ 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. If stateless session tickets are used, this information must be stored -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. +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