Subject: [quicwg/base-drafts] Describe interaction between QUIC and TLS regarding saved 0-RTT state (#2947)

From: Nick Harper <[email-masked]>
Date: Thu, 01 Aug 2019 13:52:12 -0700

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.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2947

-- Commit Summary --

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

-- File Changes --

    M draft-ietf-quic-tls.md (37)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2947.patch
https://github.com/quicwg/base-drafts/pull/2947.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2947

---

From: Nick Harper <[email-masked]>
Date: Thu, 01 Aug 2019 13:53:40 -0700

This could potentially also update the diagram at https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#tls-interface-summary (adding a line for the server between "Handshake Received" and "Get Handshake").

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2947#issuecomment-517453963

---

From: David Schinazi <[email-masked]>
Date: Thu, 01 Aug 2019 14:16:35 -0700

DavidSchinazi commented on this pull request.

> @@ -629,6 +632,24 @@ 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 saved 0-RTT state
+
+When a server receives a ClientHello with the "early_data" extension, it has to
+decide whether to accept or rejct 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}}). QUIC
+saves additional transport and application state in a 0-RTT session ticket, and
+imposes additional restrictions on when a server may accept early data. The TLS
+stack needs to check with the QUIC stack whether this saved state is valid for
+accepting early data.
+
+One example of such state that the QUIC stack checks when deciding whether or
+not to accept early data is the transport parameters extension. When HTTP/3
+({{QUIC-HTTP}}) is used at the application layer, the SETTINGS frame from the

I think you want an informative reference here: `{{?QUIC-HTTP}}`

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2947#pullrequestreview-269883525

---

From: Nick Harper <[email-masked]>
Date: Thu, 01 Aug 2019 15:09:06 -0700

nharper commented on this pull request.

It's already an informative ref, defined at the beginning of the file.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2947#discussion_r309916542

---

From: David Schinazi <[email-masked]>
Date: Thu, 01 Aug 2019 15:26:04 -0700

I was under the impression that we were changing to a mode where all references contain whether they're informative or normative.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2947#discussion_r309920816

---

From: Nick Harper <[email-masked]>
Date: Thu, 01 Aug 2019 16:40:34 -0700

>From doing git grep, the only reference to a QUIC-* draft that is marked with a `?` is the transport draft referencing QUIC-MANAGEABILITY. The rest omit a `?` or a `!`.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2947#discussion_r309936757

---

From: Mike Bishop <[email-masked]>
Date: Fri, 16 Aug 2019 12:06:32 -0700

MikeBishop approved this pull request.

Minor typos, but I think this is worth mentioning in the TLS draft.

Because the QUIC-* drafts get published at the same time, the references between them are more manual than the others.  Therefore, they get explicitly listed as a normative/informative dependency and the inline status isn't needed.

```suggestion
decide whether to accept or reject early data from the client. Some of this
```

```suggestion
resumed was included in the ClientHello; see Section 4.2.10 of {{!TLS13}}). QUIC
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2947#pullrequestreview-276119979

---

From: Nick Harper <[email-masked]>
Date: Fri, 16 Aug 2019 13:09:54 -0700

@nharper pushed 1 commit.

b13e382ca1df40e5ca5ae24268b809d178e5e763  Apply suggestions from code review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2947/files/1b58cea6eafc127dcf2d36ffaf795eddacd6d701..b13e382ca1df40e5ca5ae24268b809d178e5e763

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Aug 2019 18:35:04 -0700

martinthomson requested changes on this pull request.

> @@ -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 ---------|            |
+|            |<------- Handshake Keys -------|            |
+|   QUIC     |<--------- 1-RTT Keys ---------|    TLS     |

We probably need to move the QUIC and TLS labels up by a line.

```suggestion
## Validating 0-RTT Configuration
```

+## Validating saved 0-RTT state
+
+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

```suggestion
decision is made by the TLS stack (e.g., checking that the cipher suite being
```

+## Validating saved 0-RTT state
+
+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}}). QUIC
+saves additional transport and application state in a 0-RTT session ticket, and

QUIC doesn't save anything.  This is an implementation choice.  The key point is that QUIC requires that servers associate session configuration information with a resumed session.  The right thing to say here is that QUIC requires that a server be able to recover transport parameters for a resumed session, and different application protocols that use QUIC might have similar requirements regarding their configuration.  If transport parameters or application protocol configuration associated with a resumed session is not compatible with the current configuration of the server, the server MUST reject 0-RTT.

+decide whether to accept or reject early data from the client. Some of this
+resumed was included in the ClientHello; see Section 4.2.10 of {{!TLS13}}). QUIC

Transport parameters are the exhaustive set of things that the transport cares about.  But this implies otherwise.  I would concentrate on mentioning the h3 settings as an example of the sort of things that might be included.

Yes, we could define an extension to QUIC (the transport) that allowed state to be associated with a resumed sessions in a way that would affect this, but we don't need to do that now and our future selves can worry about how to integrate that with 0-RTT.

+
+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}}). QUIC
+saves additional transport and application state in a 0-RTT session ticket, and
+imposes additional restrictions on when a server may accept early data. The TLS
+stack needs to check with the QUIC stack whether this saved state is valid for
+accepting early data.
+
+One example of such state that the QUIC stack checks when deciding whether or
+not to accept early data is the transport parameters extension. When HTTP/3
+({{QUIC-HTTP}}) is used at the application layer, the SETTINGS frame from the
+previous session is another such example. This list is not intended to be
+exhaustive; future applications using QUIC may impose different restrictions.

```suggestion
For example, HTTP/3 ({{QUIC-HTTP}}) settings determine how 0-RTT from the client
is interpreted. Other applications using QUIC could have different requirements
for determining whether to accept or reject 0-RTT.
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2947#pullrequestreview-276309916

---

From: Nick Harper <[email-masked]>
Date: Thu, 22 Aug 2019 16:24:06 -0700

~~~

Moved up a line, and moved QUIC right one column.

I think we're trying to say the same things, just in different ways. My mention of saving state was assuming stateless session tickets; now it describes that servers must associate transport/application configuration with the TLS session ticket in addition to mentioning storing state in stateless session tickets.

I've rewritten most of this paragraph incorporating some of your language here. My overall goal of this section is to describe the features that a TLS stack needs to provide for QUIC (without prescribing API design).

Done.

Done.

+

I incorporated similar language into the new/rewritten paragraph.

I removed the mention of transport parameters specifically here, and rewrote this paragraph. My intention is to be vague so someone modifying a TLS stack to support QUIC doesn't say "let me check that transport params are compatible in the TLS stack, and then I'm done and don't need to provide a way for QUIC to reject early data", and instead actually delegates this decision to QUIC.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2947#discussion_r315394170

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Aug 2019 17:16:38 -0700

martinthomson approved this pull request.

Assuming you take my suggestions, this is good.

>  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

```suggestion
  and determining if it is valid to accept early data
```

>  primary functions:
 
 - Sending and receiving handshake messages
+- Processing stored transport and application state from a 0-RTT capable session

s/0-RTT capable session ticket/resumed session/

```suggestion
- Processing stored transport and application state from a resumed session
```

As before with the mention of tickets; and early data is already covered.

> @@ -644,6 +647,27 @@ A client MAY attempt to send 0-RTT again if it receives a Retry or Version

+## Validating 0-RTT configuration

```suggestion

+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

```suggestion
interpreted. Other applications using QUIC could have different requirements
```

> +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.

```suggestion
for determining whether to accept or reject early data.
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2947#pullrequestreview-278745896

---

From: Nick Harper <[email-masked]>
Date: Thu, 22 Aug 2019 22:50:53 -0700

c09d599bade53a8faea33a264c21d1a57de2d179  Apply suggestions from code review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2947/files/bee95016e3be73001dba5efdae015312a4659a2c..c09d599bade53a8faea33a264c21d1a57de2d179