Subject: [quicwg/base-drafts] Don't levy requirements on non-QUIC TLS endpoints (#2174)

From: ekr <[email-masked]>
Date: Thu, 13 Dec 2018 16:24:05 -0800

Section 8.2 says:

```
Endpoints MUST NOT send this extension in a TLS connection that does not use
QUIC (such as the use of TLS with TCP defined in {{!TLS13}}).  A fatal
unsupported_extension alert MUST be sent if this extension is received when the
transport is not QUIC.
```

However, this directly contradicts TLS 1.3 https://tools.ietf.org/rfcmarkup?doc=8446#section-4.1.2, which says:

```
Servers MUST ignore unrecognized extensions.
```

In order to say this, this document would need to Update 8446, and even then it doesn't make sense because the presumptive point of this rule is to detect attempts to negotiate QUIC with non-QUIC TLS endpoints, which don't need to conform to this RFC (and may predate it).

-- 
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/issues/2174

---

From: MikkelFJ <[email-masked]>
Date: Thu, 13 Dec 2018 16:42:40 -0800

I don't think QUIC can tell anyone what do with regard to any protocol that is not QUIC. And since QUIC v1 carries its own TLS record wrapping it makes even less sense.

-- 
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/issues/2174#issuecomment-447173198

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 14 Dec 2018 00:47:00 +0000 (UTC)

I agree with the problem statement, however I wonder if this opens a session ticket obtained using TLS13-over-TCP to be used in QUIC. Is that what we want?

-- 
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/issues/2174#issuecomment-447173959

---

From: ekr <[email-masked]>
Date: Thu, 13 Dec 2018 16:55:53 -0800

@kazuho: why would this text have an impact on that? Couldn't I negotiate TLS 1.3 over TCP  w/o extension and then send the resume over QUIC w/ extension?

-- 
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/issues/2174#issuecomment-447175515

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Dec 2018 16:59:45 -0800

The point here is to insist on the alert if the extension is understood.  This wasn't intended to supersede 8446.

-- 
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/issues/2174#issuecomment-447176211

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 13 Dec 2018 17:03:01 -0800

@ekr My bad. I was confused with the earlier versions of the QUIC-TLS draft that had the transport_parameters extension in the session tickets.

-- 
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/issues/2174#issuecomment-447176759

---

From: ekr <[email-masked]>
Date: Fri, 14 Dec 2018 01:11:40 +0000 (UTC)

@martinthomson I think you could phrase that, but is it useful, given that we can't rely on it?

-- 
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/issues/2174#issuecomment-447178409

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Dec 2018 18:00:39 -0800

Probably not.  I'm OK with culling the text.

-- 
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/issues/2174#issuecomment-447186978