Subject: [quicwg/base-drafts] It's just TLS (#2044)

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Nov 2018 14:41:47 -0800

For the most part, we don't need to identify TLS 1.3 specifically.  TLS
on its own is often sufficient.  This avoids creating the impression
that we don't support TLS 1.4.  I hope that TLS 1.4 will be compatible
with QUIC, but we'll leave that determination for later.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * It's just TLS

-- File Changes --

    M draft-ietf-quic-tls.md (39)
    M draft-ietf-quic-transport.md (10)

-- Patch Links --

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

---

From: MikkelFJ <[email-masked]>
Date: Thu, 22 Nov 2018 16:32:44 -0800

That is not very precise:

You have document that describes how to use with 1.3, implying one could use any other version. Presumably this happens by detecting the TLS version in the handshake so the same QUIC version could support multiple TLS versions. It could also mean different QUIC versions support different TLS versions. Further, it could mean that TLS 1.0 is supported, but not specified. This opens to downgrade attacks such as loss of perfect forward secrecy. It also makes it hard to decipher the spec.

I think it is fine to more relaxed about TLS as a building block, especially with an eye towards the feature, and perhaps also the past since TLS 1.2 might be more IoT friendly. However, a specific QUIC version needs to define a specific TLS version or set of TLS versions that are all mandatory.

-- 
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/2044#issuecomment-441137560

---

From: MikkelFJ <[email-masked]>
Date: Thu, 22 Nov 2018 16:40:27 -0800

To be fair the text does so TLS means 1.3 or newer, but I still think it is hard to ensure compatibility with random future TLS versions, 20 years out. There might not even by a HKDF function and header protection might not make sense in terms of available TLS algorithms.

-- 
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/2044#issuecomment-441138041

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Nov 2018 16:43:54 -0800

@mikkelfj, please read https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#tls-version  We're not committing to support of arbitrary versions.  TLS <=1.2 is explicitly forbidden; TLS >1.3 only works if it meets the API requirements in the TLS doc.

-- 
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/2044#issuecomment-441138267

---

From: ekr <[email-masked]>
Date: Fri, 23 Nov 2018 11:11:16 -0800

ekr 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/2044#pullrequestreview-178012006

---

From: Mike Bishop <[email-masked]>
Date: Mon, 26 Nov 2018 12:28:28 -0800

MikeBishop 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/2044#pullrequestreview-178485376

---

From: Martin Thomson <[email-masked]>
Date: Mon, 26 Nov 2018 15:28:22 -0800

Merged #2044 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/2044#event-1988172377