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

From: Nick Harper <[email-masked]>
Date: Fri, 06 Sep 2019 11:54:04 -0700

Do I need to take any action to get this PR merged? (Should this be labeled editorial?)

-- 
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-528972926

---

From: Martin Thomson <[email-masked]>
Date: Sun, 08 Sep 2019 18:13:14 -0700

I think that this is borderline editorial, as you more or less have to do this.  It does change the API, which is enough of a change that it's worth having an issue.  I'll open an issue and ask the chairs to call consensus.

-- 
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-529267154

---

From: Marten Seemann <[email-masked]>
Date: Sun, 08 Sep 2019 18:26:50 -0700

marten-seemann approved this pull request.

-- 
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-285249524

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 08 Sep 2019 18:27:04 -0700

kazuho commented on this pull request.

The text looks like a nice improvement :+1: :+1:. LGTM modulo the point below.

> @@ -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

While it is true that additional transport state needs to be associated and verified when doing 0-RTT resumption, I am not sure if that necessarily mean that "this information must be stored in the session ticket."

For example, a server might store the associated states in a NEW_TOKEN token, that also contains the hash value of the session ticket. In such a design, when accepting a new connection, a server can consult the pair of the token and the session ticket, and decide if it can accept 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-285249466

---

From: Christian Huitema <[email-masked]>
Date: Thu, 12 Sep 2019 22:12:08 -0700

I opened a related issue -- #3028. The conversation above focuses on the server, but what about ticket handling by the client? Current ticket stores are per SNI. Should they become per-SNI + per-ALPN? 

-- 
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-531100443

---

From: MikkelFJ <[email-masked]>
Date: Thu, 12 Sep 2019 22:55:44 -0700

> Should they become per-SNI + per-ALPN?

Does it even make sense to assume ALPN is always present in multiplexing protocols? An endpoint could have multiple active protocols on the same connection even if that is not supported by any protocol we currently know of.

-- 
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-531108737

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Sep 2019 22:58:45 -0700

ALPN is required by 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#issuecomment-531109335

---

From: MikkelFJ <[email-masked]>
Date: Thu, 12 Sep 2019 23:01:59 -0700

This is borderline off topic - but if ALPN is visible and firewalls use this to block traffic, endpoints might want to hide the ALPN. I suppose there is some ongoing work on ALPN encryption?

-- 
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-531109984