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

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

@kaduk said:
> 
> Section 5.2
> 
>    This secret is determined by using HKDF-Extract (see Section 2.2 of
>    [HKDF]) with a salt of 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a and
>    a IKM of the Destination Connection ID field.  This produces an
>    intermediate pseudorandom key (PRK) that is used to derive two
>    separate secrets for sending and receiving.
> 
> [I was going to say something about all-zeros providing the same level
> of cryptographic protection, but then I saw the discussion at
> https://github.com/quicwg/base-drafts/issues/4325 and the note further
> down that new versions of QUIC should pick different salt values.]
> I assume this holds for the final RFC version as compared to the I-Ds,
> and https://github.com/quicwg/base-drafts/pull/3711 suggests that a new
> (random) salt should be chosen for the final RFC version, but I didn't
> see an open issue in github for it, so I'll mention it here just in case
> that helps.  (The retry key+nonce in §5.8 seem to be in a similar boat,
> and the examples in the appendix would need to be adjusted as well, of
> course.)
> 
>    initial_secret = HKDF-Extract(initial_salt,
>                                  client_dst_connection_id)
> 
>    client_initial_secret = HKDF-Expand-Label(initial_secret,
>                                              "client in", "",
>                                              Hash.length)
>    server_initial_secret = HKDF-Expand-Label(initial_secret,
>                                              "server in", "",
>                                              Hash.length)
> 
> (editorial) I wonder a bit if the rhetoric would be more clear if we did
> not call the "initial_secret" a "secret", since it is just an
> intermediate value used for constructing secrets and not used directly
> to construct keys, itself.  (The idea would be to hew to the TLS 1.3
> terminology where specific named Secrets are used to drive
> Derive-Secret() calls but other cryptographic inputs are not named with
> the word "secret".)

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

---

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

You presume correctly about the salt.  The final salts are in place in -33, which is what you are reading, so that's good.  Unless something goes terribly wrong, this won't change any more now.  The values have been validated by a number of stacks, so I think we're good there.

As for the variable name, that's reasonable, but that same variable name is used in the examples and I think that "secret" alone in that context makes it harder to understand.

As for calling it a secret at all, TLS generally has two layers of secrets: the central secrets that are extracted using HKDF-Extract and those leaf secrets that are diversified from the central secrets using Derive-Secret().  As we don't need diversification, this skips the latter step (and all the hashing that entails).  I don't see any problem with ambiguity about whether this is analogous to a central or leaf secret in that light.

My proposal is to make no change here.

-- 
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/4490#issuecomment-755095782

---

From: kaduk <[email-masked]>
Date: Sat, 09 Jan 2021 20:28:49 -0800

> You presume correctly about the salt. The final salts are in place in -33, which is what you are reading, so that's good. Unless something goes terribly wrong, this won't change any more now. The v…

Happy to hear it -- I wasn't sure if the plan was to drop in new values as late as AUTH48 or something.

> My proposal is to make no change here.

Sounds 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/issues/4490#issuecomment-757413233

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 10 Jan 2021 13:14:29 -0800

Since the Comment Maker is happy to close with no action, that is what I'm doing.

-- 
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/4490#issuecomment-757545041

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 10 Jan 2021 13:14:30 -0800

Closed #4490.

-- 
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/4490#event-4188440120