IETF Logo Mail Archive

Re: [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)

Dan Brown <danibrown@blackberry.com> Fri, 08 May 2020 21:29 UTC

Return-Path: <danibrown@blackberry.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2530B3A0F3B; Fri, 8 May 2020 14:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=blackberry.com
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 pxIeoOZsukI3; Fri, 8 May 2020 14:29:07 -0700 (PDT)
Received: from smtp-pg10.blackberry.com (smtp-pg10.blackberry.com [68.171.242.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE463A0F3E; Fri, 8 May 2020 14:29:06 -0700 (PDT)
Received: from pps.filterd (mhs400ykf.rim.net [127.0.0.1]) by mhs400ykf.rim.net (8.16.0.27/8.16.0.27) with SMTP id 048LSGFE051853; Fri, 8 May 2020 17:28:16 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blackberry.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=corp19; bh=nPtlUTftz9dwIj2H+hDB0QjHMxKAa8HGgV7lpp4dOPs=; b=GP2ba45dBGUzNIlnH8KkEOgpPYSmjicfw+JisGxFJv7pekepYghc6QQNX2T0OyWG1ktF 9Wj5UCtBuUds3ETGc+ogJ+vHF2ILxZg/vctiXCQcYKuMQFZm0tFlxefICLJQs6MZ6I49 phtkm16VyGMrKvy9UXhnOYMedLvivLLjN7hU63pnTopIf4Q2UJkre0BTHF0G5LH62CVZ 2F+6NBFf9xKCiy1yso5oX0v+uPxM7YobT4Te448UZfLGmHB51vAZb3Zv8ivnQmKehB+5 7KpYN2sw2y8+tO/mNFE0vJc1iOYhCdJYICArk/JoCOZnFxJULahBlOnakZx043fmnrjA oA==
Received: from xch213ykf.rim.net (xch213ykf.rim.net [10.2.27.113]) by mhs400ykf.rim.net with ESMTP id 30vk15b2bq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 08 May 2020 17:28:16 -0400
Received: from XCH210YKF.rim.net (10.2.27.110) by XCH213YKF.rim.net (10.2.27.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 8 May 2020 17:28:15 -0400
Received: from XCH210YKF.rim.net ([fe80::81ca:ad34:fc3:5ce8]) by XCH210YKF.rim.net ([fe80::81ca:ad34:fc3:5ce8%5]) with mapi id 15.01.1913.007; Fri, 8 May 2020 17:28:15 -0400
From: Dan Brown <danibrown@blackberry.com>
To: "Salz, Rich" <rsalz@akamai.com>, "tls@ietf.org" <tls@ietf.org>, "cfrg@ietf.org" <cfrg@ietf.org>
Thread-Topic: NIST crypto group and HKDF (and therefore TLS 1.3)
Thread-Index: AQHWJXY75SUMYNJzo0q8VSbsRy8U7aiep7QAgAAXq4D///L4IA==
Date: Fri, 08 May 2020 21:28:15 +0000
Message-ID: <8d29849bb48642fa94258093f0440aaf@blackberry.com>
References: <07D37E65-0951-49BB-B86E-BD3167ADB352@akamai.com> <9bae52f88d99421cbae6ab362e52c0a3@blackberry.com> <83724575-D77E-4E1C-89E9-7550D816C451@akamai.com>
In-Reply-To: <83724575-D77E-4E1C-89E9-7550D816C451@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [100.64.97.74]
Content-Type: multipart/signed; micalg="2.16.840.1.101.3.4.2.1"; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_00A6_01D6255E.0DAFB1E0"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-08_19:2020-05-08, 2020-05-08 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/tjEcATXAsFpezkJ9etsWMhhp8iY>
Subject: Re: [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2020 21:29:12 -0000

> -----Original Message-----
> From: Salz, Rich <rsalz@akamai.com>
>
> >    [DB] But NIST Draft SP 800-56Cr2 cites RFC 5869, which is HKDF, and 
> > says
> HKDF
>     is a version of 56C Section 5.1. So, I had thought that 56C would allow 
> HKDF.
>     What am I missing?
>
> It cites it, but doesn't include it in the 800-56 doc.

To be clear, are you saying that RFC 5869 HKDF is not compatible with 
800-56Cr2?

(I had assumed they were compatible, but just used different notation for the 
same idea.)

Looking just now, I see 800-56C refers to 800-108, whose Section 5.2, KDF in 
Feedback Mode looks really close to HKDF in RFC 5869.  I see the same overall 
design, but some different orderings of inputs, which could cause non-interop. 
Is that the case?


----------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

v2.23.0 | Report a Bug | By Email