Re: [TLS] TLS1.3 HkdfLabel - value of label<0..6> ?
Hugo Krawczyk <hugo@ee.technion.ac.il> Mon, 01 April 2019 02:38 UTC
Return-Path: <hugokraw@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A18120044 for <tls@ietfa.amsl.com>; Sun, 31 Mar 2019 19:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WE8YnF2I_W57 for <tls@ietfa.amsl.com>; Sun, 31 Mar 2019 19:38:10 -0700 (PDT)
Received: from mail-it1-f180.google.com (mail-it1-f180.google.com [209.85.166.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67FFF12002E for <tls@ietf.org>; Sun, 31 Mar 2019 19:38:10 -0700 (PDT)
Received: by mail-it1-f180.google.com with SMTP id y63so12855058itb.5 for <tls@ietf.org>; Sun, 31 Mar 2019 19:38:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UZ1jp1O6t/zRKNZ8GLWQpEU6J8cuHYUJXYhDKx72p/I=; b=Q4JLVobn82nZUR14x7mL6BJmHkW7CN4EtnL4pq2JQ91UXskI0vxhp3nWdOkUYeym+m woIdhaJ6M9IHU9GcbtuZbvYqXgNbKjoJMIgmORlJ9x5e1d01scoVTCcH3n8DYMxnVanP dmravFkrbMWsR1xtg6bvikiiNqWLojyTv96afWrlMcuMb8Ci1SahwXnIW37SWoa/lBld fSoCQcBv5q2lgJ+bOmrYxTgx56wM3/WbmkJmyTc0QgqEf4aYLykr+O3BjTBNXeTR5cCa VO2+Y6+5mRtdTmZNdorPT4J2igtE0H3FgJHslhAH3L8iS9kcov3SCcOmGiO34Xm254vi ea8w==
X-Gm-Message-State: APjAAAWkhAjx0OwBVgAGt0cQ9+4oR7L6nAdI5iQoaqfvAxuMyFTzup1K Z66ptFLAHealHuE7RxUBPdxm0BAvMyi/kZADcrY=
X-Google-Smtp-Source: APXvYqxZEa6d16Ih0WzDIHpo1jk56fyxbFIKXgLm/VK33EgkhGud2UxRZMzp19PBlSA4oIxHUxuGzUXts93y4Lqq0KQ=
X-Received: by 2002:a05:660c:1282:: with SMTP id s2mr2593904ita.47.1554086289355; Sun, 31 Mar 2019 19:38:09 -0700 (PDT)
MIME-Version: 1.0
References: <CAG5P2e-M8qAWzUjtz3fbAOOc6xmPNy19NMS2d6yFCHOegF8t8w@mail.gmail.com> <20190331134600.GA31227@LK-Perkele-VII> <7AA7375A-98EA-49F4-B749-7967E4031D42@ll.mit.edu>
In-Reply-To: <7AA7375A-98EA-49F4-B749-7967E4031D42@ll.mit.edu>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Sun, 31 Mar 2019 22:37:43 -0400
Message-ID: <CADi0yUOAmPbj0VJ9sVf3SHC-iM=3L032rimyJP9-sgS6f8+KgA@mail.gmail.com>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003a364305856ee920"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ecUQj8uae5PTgHQGdKmr5APo4Bo>
Subject: Re: [TLS] TLS1.3 HkdfLabel - value of label<0..6> ?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2019 02:38:14 -0000
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 < uri@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 <ilariliusvaara@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] TLS1.3 HkdfLabel - value of label<0..6> ? M K Saravanan
- Re: [TLS] TLS1.3 HkdfLabel - value of label<0..6>… Ilari Liusvaara
- Re: [TLS] TLS1.3 HkdfLabel - value of label<0..6>… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] TLS1.3 HkdfLabel - value of label<0..6>… M K Saravanan
- Re: [TLS] TLS1.3 HkdfLabel - value of label<0..6>… Hugo Krawczyk