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 < u...@ll.mit.edu> 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 > > > On Mar 31, 2019, at 09:46, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > >> On Sun, Mar 31, 2019 at 08:38:47PM +0800, M K Saravanan wrote: > >> 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>? > > > > 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 > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
