Subject: [TLS] TLS1.3 HkdfLabel - value of label<0..6> ?

From: M K Saravanan <[email-masked]>
Date: Sun, 31 Mar 2019 20:38:47 +0800

Hi,

https://tools.ietf.org/html/rfc8446
============
7.1.  Key Schedule

   The key derivation process makes use of the HKDF-Extract and
   HKDF-Expand functions as defined for HKDF [RFC5869], as well as the
   functions defined below:

       HKDF-Expand-Label(Secret, Label, Context, Length) =
            HKDF-Expand(Secret, HkdfLabel, Length)

       Where HkdfLabel is specified as:

       struct {
           uint16 length = Length;
           opaque label<7..255> = "tls13 " + Label;
           opaque context<0..255> = Context;
       } HkdfLabel;
============

In this struct, what is the value of label<0..6>?

with regards,
Saravanan

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 31 Mar 2019 16:46:00 +0300

> https://tools.ietf.org/html/rfc8446

The syntax "opaque label<7..255>" means that label is octet string of
at least 7 and at most 255 octets, and that its length is encoded using
1 octet. The string "tls13 " is 6 octets long, so that impiles that
Label is at least 1 octet and at most 249 octets long.

So for example if Label is "s hs traffic", then the label (including
the length field) is:

\x12 "tls13 s hs traffic"

The \x12 is the octet with value 18 (which happens to be ASCII DC2)
because the remainder is 18 octets.

And as another example if Label is "c e traffic", then the label
(again including length field is: 

\x11 "tls13 c e traffic"

The \x11 is the octet with value 17 (which happens to be ASCII DC1)
because the remainder is 17 octets.

In the first case, if the ciphersuite has SHA-256 hash, then the
whole HkdfLabel looks like the following (in hex):

00 20					#32 octets of output (2 octets)
12					#18 octets label length (1 octet)
"tls13 s hs traffic"			#The actual label (18 octets)
20					#32 octet transcript input (1 octet).
hash(client_hello+server_hello)		#Transcript (32 octets).

In total, this is 54 bytes (64 bytes after adding HKDF and SHA-256
internal overhead). There is only one output block, and the input
fits into one block so evaluating the HKDF-Expand takes 4 SHA-256
block operations.

The one ciphersuite using SHA-384 would instead give (in hex):

00 30					#48 octets of output (2 octets)
12					#18 octets label length (1 octet)
"tls13 s hs traffic"			#The actual label (18 octets)
30					#48 octet transcript input (1 octet).
hash(client_hello+server_hello)		#Transcript (48 octets).

In total, 70 bytes. Again, only one output block and only one input
block, so evaluation takes 4 SHA-384 block operations.

-Ilari

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 31 Mar 2019 17:48:53 +0000

A naive question: is HKDF implemented placing secret in the "salt" argument, and label in the "key" argument, as NIST 800-56B says? Or putting label into "salt" and secret into "key"?

Regards,
Uri

Sent from my iPhone

> On Mar 31, 2019, at 09:46, Ilari Liusvaara <[email-masked]> wrote:
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: M K Saravanan <[email-masked]>
Date: Mon, 1 Apr 2019 07:40:48 +0800

> Label is at least 1 octet and at most 249 octets long.
[...]

Thank you so much for the detailed clarification with examples.

with regards,
Saravanan

---

From: Hugo Krawczyk <[email-masked]>
Date: Sun, 31 Mar 2019 22:37:43 -0400

What Illari describes is in accordance to TLS 1.3, which uses HKDF-Expand
correctly (as defined in RFC 5869 and the related extract-then-expand
scheme from
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr1.pdf,
Fig 1 in pg 18).
That is, it uses the "secret" as a key to HMAC (where secret is derived, in
most cases, from the preceding HKDF-Extract step, not shown in Illari
description) and the label as replacing the message input in HMAC.

The salt, to which you allude, is used in HKDF-Extract that applies HMAC
with the HMAC key replaced by a random salt if available and zero salt
otherwise, and with the keying material as the input, i.e., replacing the
message in HMAC. No label or other information is concatenated to the
keying  material,

Hugo

On Sun, Mar 31, 2019 at 1:49 PM Blumenthal, Uri - 0553 - MITLL <
[email-masked]> wrote:

> A naive question: is HKDF implemented placing secret in the "salt"
> argument, and label in the "key" argument, as NIST 800-56B says? Or putting
> label into "salt" and secret into "key"?
>
> Regards,
> Uri
>
> Sent from my iPhone
>