Subject: [quicwg/base-drafts] Separation for leaf keys only (#1991)

From: Martin Thomson <[email-masked]>
Date: Sun, 11 Nov 2018 21:44:35 -0800

Remove the "quic " label from HKDF-Expand-Label, and add it to the leaf key derivation steps.

There is also [a story with pictures explaining this change](https://gist.github.com/martinthomson/c254bbc4214e8b3d4f38372b9afce18d#file-key-schedule-md).

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

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

-- Commit Summary --

  * Remove "quic " HKDF label
  * Remove example
  * Separate keys at the leaves

-- File Changes --

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

-- Patch Links --

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

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 11 Nov 2018 22:20:22 -0800

Will DTLS use the same approach; i.e. use "tls13 dtls key" and "tls13 dtls iv" for it's traffic key generation?

This might sound like an off-topic question, but I would like to confirm that we are having a consistent pattern among the flavors of TLS.

-- 
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/1991#issuecomment-437769428

---

From: Martin Thomson <[email-masked]>
Date: Sun, 11 Nov 2018 22:24:26 -0800

Good question.  I hadn't considered the possibility of providing better separation between TLS and DTLS.  In that case, it might be more reasonable to use a different base label (i.e., something like "dtls13 key" or "dtls13 iv").  @ekr, WDYT?

-- 
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/1991#issuecomment-437770145

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 11 Nov 2018 22:27:10 -0800

FWIW, I think using the same prefix (i.e. `tls13 `) throughout makes sense. What we need is a separation at traffic key level, and for that purpose using the proposed "_handshake-protocol_ _traffic-type_ (key|iv|pn)" format seems logical to me.

-- 
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/1991#issuecomment-437770622

---

From: Marten Seemann <[email-masked]>
Date: Sun, 11 Nov 2018 23:32:57 -0800

The TLS spec notes that
> with common hash functions, any label longer than 12 characters requires an additional iteration of the hash function to compute. The labels in this specification have all been chosen to fit within this limit.

Should that be a design criterion for us as well?

-- 
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/1991#issuecomment-437783337

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Nov 2018 09:35:07 +0000 (UTC)

Yes, I consider that.  "quic key" is short enough.

-- 
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/1991#issuecomment-437814547

---

From: Marten Seemann <[email-masked]>
Date: Mon, 12 Nov 2018 01:47:21 -0800

Maybe I'm not understanding the key derivation correctly, but isn't the label prepended with "tls13 "? This would add another 6 characters, so "tls13 quic key" would be 14 characters in total.

-- 
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/1991#issuecomment-437818107

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Nov 2018 01:59:37 -0800

I seem to remember that the calculation allows for the 'tls13 ' prefix.  The real constraint is on the total length of the input to HKDF, which needs to be less than 32.  

```
       struct {
           uint16 length = Length;  // 2
           opaque label<7..255> = "tls13 " + Label; // 7 + len(Label)
           opaque context<0..255> = Context; // 1 + len(Context)
       } HkdfLabel;
```

Given that HKDF adds 1 more to this, that means there are 11 octets taken with overheads.  Context is either 0 length or a full hash width, so that doesn't factor in.  I don't know how this translates to 12 remaining (for a total of 23), I would have thought that the limit was 21.  Maybe there was some transposition of characters involved.

-- 
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/1991#issuecomment-437821912

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 12 Nov 2018 04:40:44 -0800

Yeah my understanding is that `sizeof(HkdfLabel) - 1` needs to be equal to or smaller than the block size of the hash function (e.g. 64 octets in SHA256).

In our case, `len(Context)` is zero, so I'd assume that we have even more space than 21 octets :-)

Anyways, "tls13 quic key" is perfectly fine.

-- 
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/1991#issuecomment-437865021

---

From: Antoine Delignat-Lavaud <[email-masked]>
Date: Mon, 12 Nov 2018 10:33:43 -0800

Pushing this logic, it could make sense to also include the QUIC version in the transport key labels. Then, if some other version of QUIC comes up with a serious version authentication flaw, other versions may not be affected by cross-protocol/cross-version attacks.

-- 
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/1991#issuecomment-437984632

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Nov 2018 15:58:13 -0800

@martinthomson pushed 1 commit.

1e4ab00  Add key diversity section

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1991/files/35a7bb0dcc3598be6d4ae86c47af99a1a839ccc7..1e4ab004ce00f2f5ee72870b94187e434a6e3159

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Nov 2018 14:58:17 -0800

Merged #1991 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/1991#event-1978690373