Subject: [quicwg/base-drafts] Describe inputs to TLS more clearly (#4011)

From: Martin Thomson <[email-masked]>
Date: Mon, 17 Aug 2020 19:06:01 -0700

This clarifies the TLS interface by explaining that TLS only generates
outputs (handshake bytes or keying material) in response to inputs.
Previously, the only inputs we acknowledged were the handshake bytes,
but this recognizes two more: the signal from the client to start
handshaking, and - for async validation - a signal that a certificate is
OK or not.

Closes #3873.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Describe inputs to TLS more clearly

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/4011.patch
https://github.com/quicwg/base-drafts/pull/4011.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/4011

---

From: Marten Seemann <[email-masked]>
Date: Mon, 17 Aug 2020 20:19:46 -0700

@marten-seemann commented on this pull request.

> @@ -499,9 +499,17 @@ handshake, new data is requested from TLS after providing received data.
 ### Encryption Level Changes
 
 As keys at a given encryption level become available to TLS, TLS indicates to
-QUIC that reading or writing keys at that encryption level are available.  These
-events are not asynchronous; they always occur immediately after TLS is provided
-with new handshake bytes, or after TLS produces handshake bytes.
+QUIC that reading or writing keys at that encryption level are available.
+
+The events that cause new keys to be available are not asynchronous; they
+always occur immediately after TLS is provided with inputs. Inputs are either
+new handshake bytes or new instructions. The two instructions that this
+document relies upon are the initial signal to start the handshake and - if the
+TLS implementation allows asynchronous certificate validation - an indication

This seems to assume that certificate validation is done "outside" of the TLS library if it's done asynchronously. I can imagine a design where certificate validation happens "inside" the TLS stack, where the QUIC stack still decides to not block on the result.

-- 
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/4011#pullrequestreview-468963829

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 17 Aug 2020 21:03:16 -0700

Weren't we going to say that the traffic keys might get generated asynchronously in #3874? I wonder how this PR interacts with #3874.

I see this PR calling out three types of events (i.e. generation of CH, input of handshake bytes, completion of certificate validation) as the "inputs," then claim that TLS provides the keys "synchronously" in relation to such events. That works as a definition, but I am not sure if it is easy to comprehend.

I think my preference would be to talk about (a)synchronicity from the viewpoint of a transport. It would be easier to say that TLS might provide keys "asynchronously" from what the transport provides as input, then point out that key generation (possibly in relation to certificate verification) might take some time.

-- 
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/4011#issuecomment-675235920

---

From: Martin Thomson <[email-masked]>
Date: Mon, 17 Aug 2020 21:05:29 -0700

To answer both questions, I am planning on integrating the text from #3874 as well.  That would cover the case where the TLS stack has to disappear for some time before it produces new outputs, however that manifests.

-- 
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/4011#issuecomment-675236487