Subject: [quicwg/base-drafts] TLS application data isn't possible (#3043)

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Sep 2019 21:48:30 -0700

This is a point @martinduke makes in #3039, but it probably pays to make it more clearly.  This was possible in earlier iterations of the draft, so it&#39;s worth stamping out residual mentions.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Remove &#39;given&#39;
  * QUIC only carries TLS handshake and alert

-- File Changes --

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

-- Patch Links --

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

---

From: Marten Seemann <[email-masked]>
Date: Mon, 16 Sep 2019 23:26:33 -0700

marten-seemann commented on this pull request.

 QUIC takes the unprotected content of TLS handshake records as the content of
 CRYPTO frames. TLS record protection is not used by QUIC. QUIC assembles
 CRYPTO frames into QUIC packets, which are protected using QUIC packet
 protection.
 
+QUIC is only capable of conveying TLS handshake records in CRYPTO frames.  TLS
+alerts are turned into QUIC CONNECTION_CLOSE error codes; see {{tls-errors}}.
+TLS application data and other message types cannot be carried by QUIC at any
+encryption level and can be treated as an error if they are received.

How would it look like if they were received?
Wasn't @martinduke's point that QUIC doesn't even provide a way to send them at all, since there are no record headers?

-- 
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/3043#pullrequestreview-289040833

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Sep 2019 00:45:35 -0700

martinthomson commented on this pull request.

Sorry, I meant to say "...by a QUIC implementation".

-- 
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/3043#discussion_r325023746

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Sep 2019 07:46:13 +0000 (UTC)

@martinthomson pushed 1 commit.

3a813cdab5b53aeb5cbb3064f9046dcf6179eddd  received from TLS

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3043/files/136cd0176ad9815a42f7ae6fb484956efcc74873..3a813cdab5b53aeb5cbb3064f9046dcf6179eddd

---

From: Marten Seemann <[email-masked]>
Date: Tue, 17 Sep 2019 01:05:11 -0700

Still not sure how this could happen (I don't think it could in quic-go), but I guess that depends very much on the details of the coupling between your QUIC implementation and your TLS stack.

-- 
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/3043#discussion_r325031574

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 17 Sep 2019 09:13:06 -0700

kazuho 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/3043#pullrequestreview-289382937

---

From: martinduke <[email-masked]>
Date: Tue, 17 Sep 2019 09:18:07 -0700

martinduke 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/3043#pullrequestreview-289386164

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 17 Sep 2019 13:55:02 -0700

janaiyengar commented on this pull request.

```suggestion
TLS application data and other message types cannot be carried by QUIC
```

+QUIC is only capable of conveying TLS handshake records in CRYPTO frames.  TLS
+alerts are turned into QUIC CONNECTION_CLOSE error codes; see {{tls-errors}}.
+TLS application data and other message types cannot be carried by QUIC at any
+encryption level and can be treated as an error if they are received from the

```suggestion
MAY be treated as an error if they are received from the
```

+QUIC is only capable of conveying TLS handshake records in CRYPTO frames.  TLS
+alerts are turned into QUIC CONNECTION_CLOSE error codes; see {{tls-errors}}.
+TLS application data and other message types cannot be carried by QUIC at any
+encryption level and can be treated as an error if they are received from the

Which error type? Does this result in a CONNECTION_CLOSE? Or just drop the connection? This is a local error, and therefore does not need to be communicated to the peer, so I would suggest just drop the connection. But that should be explicitly stated.

-- 
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/3043#pullrequestreview-289539545

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 17 Sep 2019 14:47:37 -0700

kazuho commented on this pull request.

This is a clarification of fact, that a TLS stack can never return application data, unless there is a bug in the TLS stack or in the way the QUIC stack uses the TLS stack.

Therefore I think that "can be treated as an error" is fine. Changing it to "is an error" would be fine too.

-- 
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/3043#discussion_r325400514

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 17 Sep 2019 15:10:49 -0700

@kazuho: Makes sense, but I think saying "is an error" is overloaded, since we have many types of errors. But, this isn't a big deal; I'm happy with @martinthomson's editorial decision here.

-- 
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/3043#discussion_r325407851

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Sep 2019 18:45:47 -0700

df5d9f102587b8fbcce1f3d815698774042bea26  is an error

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3043/files/3a813cdab5b53aeb5cbb3064f9046dcf6179eddd..df5d9f102587b8fbcce1f3d815698774042bea26

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Sep 2019 18:48:07 -0700

I'll take Kazuho's "is an error" to avoid triggering the usual "treat X as an error of type" thinking that goes along with generating CONNECTION_CLOSE.  This is just wrong.

To Marten's point about how stacks can do this - I don't think that we generate any application_data records in our stack, but we certainly have assertions in place in case we get some.  If someone accidentally writes to the TLS socket, then we'll at catch that at the earliest possible moment.

-- 
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/3043#discussion_r325451959

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Sep 2019 18:48:12 -0700

Merged #3043 into master.

-- 
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/3043#event-2641886099