Subject: [quicwg/base-drafts] Use the same KDF regardless of TLS version (#2034)

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Nov 2018 22:38:30 -0800

Follow-up for #2032, which I merged a little hastily.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Use the same KDF regardless of TLS version

-- File Changes --

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

-- Patch Links --

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

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 20 Nov 2018 22:55:51 -0800

Is the suggestion here to use the HKDF function defined in TLS 1.3 for Handshake, 0-RTT, 1-RTT packets even when the negotiated version is TLS 1.4?

I am not sure if that is a good idea, because there could be an "improvement" to the HKDF function in TLS 1.4. IMO, the use of the HKDF function of TLS 1.3 should be limited to Initial packets.

-- 
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/2034#issuecomment-440558005

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Nov 2018 23:41:15 -0800

It depends on whether you think that the upgrade to TLS is coordinated.  If it isn't, then we'll have interop failure.  If it is, that will artificially hamper 1.4 deployment.

-- 
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/2034#issuecomment-440566904

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 20 Nov 2018 23:57:25 -0800

> If it isn't, then we'll have interop failure. If it is, that will artificially hamper 1.4 deployment.

The answer depends on what type of API the TLS stacks would provide. For example, it would not be an issue for a TLS stack that exposes a “method” that creates a AEAD context from a TLS connection.

Anyways, if we are to use the same HKDF construction for TLS 1.4 and above, I do not see the reason for having the “tls13 ” prefix. Should we revert #1991 to reduce the number of changes?

-- 
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/2034#issuecomment-440570473

---

From: MikkelFJ <[email-masked]>
Date: Wed, 21 Nov 2018 02:56:07 -0800

I don't think this is safe, see discussion in #2032 https://github.com/quicwg/base-drafts/pull/2032#issuecomment-440618511

-- 
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/2034#issuecomment-440622333

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Nov 2018 12:03:13 -0800

I see where you are going, but I don't think that this is using "the current TLS KDF". That's what put us in this bind in the first place.  We have to be more concrete than that, and that means specifying exactly what to do with the secrets that TLS provides.

-- 
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/2034#issuecomment-440792817

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 21 Nov 2018 12:24:06 -0800

FWIW, I tend to agree @martinthomson that always using the TLS 1.3 HKDF for packet protection is simpler.

I can see that the TLS-version-independent construction required by #2032 can be complex depending on the TLS stack (to be honest, it would be complex in picotls too, unless we create a API like the one in 
https://github.com/quicwg/base-drafts/pull/2034#issuecomment-440570473). OTOH, it is uncertain if we would gain anything from a HKDF construction that's trying to be version-independent, there's no guarantee that the future versions of TLS uses a KDF that is API-compatible with that of TLS 1.3.

Therefore, I am not against mandating the use of TLS "1.3" HKDF for QUICv1. The only complaint I have is that, then, we do not need the "tls13 " prefix. Having it is not bad by itself, but imposes an unnecessary change to the implementors.

I feel sorry for the asking the editors to revert #1991 after spending an effort on it. But I am not sure if we can convince that the implementors #1991 is a necessary change if we adopt the text of this PR.

-- 
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/2034#issuecomment-440798186

---

From: MikkelFJ <[email-masked]>
Date: Wed, 21 Nov 2018 12:48:38 -0800

HKDF is generally designed to strengthen weak input data. With a strong session key AES-CTR could be used instead of a HMAC HKDF to derive traffic keys. To separate QUIC versions, the session key could be version saltet.

Maybe HMAC is better at protecting against weak session keys due to bad PRNGs or side-channels, but I doubt it.

If a general solution is sought, some consideration ought to be directed towards versions that do not use TLS crypto. For example a version that uses a much smaller/faster crypto subset.

-- 
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/2034#issuecomment-440803911

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Nov 2018 12:51:21 -0800

HMAC is used in TLS because it has proven security properties.  There are alternatives (a construction based on AES is one of those), but they don't have security proofs that would support the proofs of TLS.  Favouring proven primitives is the conservative approach.  If a primitive that is faster can be proven to provide the properties we require, we can determine at that point whether defining a new version is worthwhile.

-- 
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/2034#issuecomment-440804647

---

From: janaiyengar <[email-masked]>
Date: Wed, 21 Nov 2018 15:47:32 -0800

janaiyengar commented on this pull request.

> @@ -715,6 +715,11 @@ method described in Section 7.3 of {{!TLS13}}), with the labels "quic key" and
 respectively).  Using these labels provides key separation between QUIC and TLS,
 see {{key-diversity}}.
 
+The HKDF-Expand-Label function defined in TLS 1.3 MUST be used even when a
+different TLS version is negotiated, or - for Initial packets - if the TLS
+versions offered do not include TLS 1.3.  This ensures that the selection of TLS
+version is independent of the process used to derive QUIC keys.

It might be useful to describe the nuance here  -- that Initial packets are expected to be decrypted before a TLS version is negotiated, and therefore there needs to be prior agreement on the HKDF-Expand-Label function used for 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/pull/2034#pullrequestreview-177464395

---

From: Marten Seemann <[email-masked]>
Date: Wed, 21 Nov 2018 17:33:31 -0800

I’m not a fan of using the TLS 1.3 HKDF for all versions. Only that way can we ensure that TLS 1.4 can diverge from 1.3, without having to define a new QUIC version. 

Using it just for the Initial, as in Kazuho’s original PR, makes the most sense to me: I handle the obfuscation of the Initial, and after that I let the TLS stack do its thing. At least for me is the easiest to implement: I don't need to change anything in my TLS stack, I just need to make sure that the right HKDF-Expand is used for the Initial AEAD (it’s not that complex anyway - if the stack doesn’t expose it, it’s just a few lines of code to reimplement it, given that the standard library exposes all needed crypto primitives). 

-- 
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/2034#issuecomment-440883795

---

From: Alessandro Ghedini <[email-masked]>
Date: Thu, 22 Nov 2018 08:39:23 -0800

Maybe off-topic, but is negotiating a different TLS version (say, TLS 1.4) even legal right now? E.g. -transport says "Version 0x00000001 of QUIC uses TLS 1.3", not "1.3 or later" or whatever.

-- 
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/2034#issuecomment-441080796

---

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

The intent was always to permit negotiation of newer TLS versions.  That's an easy fix.

However, this discussion goes to the core of what the interface between QUIC and TLS is.  The stream0 contract, as I understood it, was that TLS would pass secrets to QUIC.  This is why we changed so that the invasive change to the TLS KDF was not allowed.  QUIC is responsible for taking those secrets and turning them into keys and IVs.

It seems like people are arguing here that the TLS KDF is also part of the contract.  As an implementation convenience, that's fine, but I don't think that's a good idea.  It means that we have inconsistent use of KDFs within QUIC (TLS 1.3 for initial keys, TLS X for other keys), and it means that the API contract is tighter.

If your QUIC stack wants to use the TLS KDF, that's fine, but this binds the call to the negotiated TLS version.  You can't just call `tls13_kdf(secret, label, L)`, you have to build `tls_kdf(tls_socket, secret, label, L)`, AND you still need the other API for initial secrets.

-- 
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/2034#issuecomment-441129242

---

From: ekr <[email-masked]>
Date: Thu, 22 Nov 2018 15:42:33 -0800

@martinthomson I'm not sure how persuasive this argument is. We already feed out the TLS 1.3 cipher suite and the HKDF settings are really part of that. Moreover, using the same KDF allows us to ensure that we don't get collisions (which is the point of the different labels). [Imagine, hypothetically, that the TLS 1.3 KDF is HKDF with the label "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/2034#issuecomment-441134372

---

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

I don't think that the collision argument is particularly relevant, because we ensure that QUIC is the exclusive user of the secret (something I think that we want to stipulate).  I always viewed the TLS negotiation as exporting just the secrets and cipher suite.  We extract AEAD and hash from the suite.  It doesn't export a keyed AEAD (it could), because that wouldn't work for header protection.  And just as QUIC provided its own AEAD, why not also a KDF?

-- 
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/2034#issuecomment-441135777

---

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

I think it is fine to have different HKDF in initial secrets. You also have AES-128-GCM in initial which might be implemented in a completely slow and sloppy manner in order to progress to a different cipher suitable for some IoT device. It makes sense to me to follow the HKDF of the negotiated cipher for the rest of the connection. This also paves the road for future more efficient HKDF algorithms if/when they become available - although likely in another QUIC version.

-- 
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/2034#issuecomment-441138419

---

From: MikkelFJ <[email-masked]>
Date: Thu, 22 Nov 2018 17:06:50 -0800

> And just as QUIC provided its own AEAD, why not also a KDF?

I think this a valid point of view - but I also think it is more precise to say that QUIC handles its own implementation and representation of the AEAD specified by TLS. It makes sense that the KDF is paired with the negotiated cipher. If for no other reason than that it provides agility of both cipher and KDF, but also because ultimately they could be related in a security proof - not in this version, but eventually.

Perhaps QUIC could benefit from a more formal crypto interface that TLS plugs into but which other frameworks could also use. This could also guide the work of future TLS versions and also future versions of QUIC. But this is easier to do when QUIC v1 is finalized or close to finalized.

-- 
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/2034#issuecomment-441139688

---

From: MikkelFJ <[email-masked]>
Date: Thu, 22 Nov 2018 17:41:52 -0800

This looks good.

-- 
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/2034#issuecomment-441141950

---

From: ekr <[email-masked]>
Date: Thu, 22 Nov 2018 20:25:20 -0800

> I don't think that the collision argument is particularly relevant, because we ensure that QUIC is the exclusive user of the secret (something I think that we want to stipulate). 

The issue here is separation between TLS and QUIC handshakes. The reason (I assume) that you are using the "quic " labels in key derivation is to ensure that the QUIC traffic keys can never be the same as the TLS ones, even though they are derived from the same secret.. However, this isn't the case if you have no idea what the TLS KDF is, as it could perversely use the "quic " labels 

-- 
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/2034#issuecomment-441154247

---

From: Martin Thomson <[email-masked]>
Date: Mon, 26 Nov 2018 19:24:55 -0800

Closed #2034 via #2046.

-- 
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/2034#event-1988466042