Subject: [quicwg/base-drafts] Ben Kaduk's TLS Comment 13 (#4489)

From: Lucas Pardue <[email-masked]>
Date: Tue, 05 Jan 2021 18:54:27 -0800

@kaduk said:

> Section 5.1
> 
> I think we should say something about the "Context" argument to
> HKDF-Expand-Label here.  (I assume it is going to be the same
> Transcript-Hash as used for TLS 1.3, but it is not currently specified,
> as far as I can see.  I do note that we have some ongoing discussion in
> the context of draft-ietf-emu-eap-tls13 that *exporters*, at least,
> might better have been specified to use the full transcript including
> client Finished, but I am not convinced that we should consider such
> drastic changes for our usage, especially since it would neuter 0.5-RTT
> unless we add a lot more complexity.)  We may also want to say that
> the Length input is determined by the ciphersuite's requirements.
> Alternately we could specify in terms of Derive-Secret(), but there's
> not really a clear incentive to do so.

-- 
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/4489

---

From: Martin Thomson <[email-masked]>
Date: Tue, 05 Jan 2021 21:40:47 -0800

Oh, so many things to unpack from a short comment...

1. Yes, Context should be explicitly empty.  I'll create a PR for this and the other, below.
2. The TLS transcript is integrated into the derivation of the keys that we use, so we don't need to include it again.  
3. As an aside, EAP-TLS1.3 use of 0x0D in the exporter is counter to the intended use of the field.  They already have all the fixed key separation necessary through the use of the exporter label.  The field is intended to capture variable, contextual information such as identities or other things that are not already folded into the handshake.
4. I agree that using a different span of the handshake transcript for key derivation would be massively disruptive, that is why I would oppose doing that.
5. As with Context, so too with Length, though that requires a little more text to address.  That's in the PR too.  Note: I had to decide between N_MAX and N_MIN and chose N_MAX.  Though the values are the same for all of the AEADs we use, that isn't guaranteed.  I'm sure that an AEAD with variable-length nonce could manage, but no sense in being imprecise.
6. I want nothing to do with Derive-Secret.  That's too far into TLS internals.

-- 
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/4489#issuecomment-755092525

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 05 Jan 2021 22:17:14 -0800

I think that the separation that we have now is good and that we do not need to change the design.

Regarding IV length, as stated in the PR review comment, we are using TLS cipher-suites. Therefore I think we should be using what is defined in TLS 1.3 (i.e. `max(8, N_MIN)`) rather than specifying a different rule.

-- 
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/4489#issuecomment-755106432

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Jan 2021 23:21:30 -0800

Closed #4489 via #4571.

-- 
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/4489#event-4178544199