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

"Dang, Quynh H. (Fed)" <quynh.dang@nist.gov> Mon, 11 May 2020 12:09 UTC

Return-Path: <quynh.dang@nist.gov>
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 775553A0A43; Mon, 11 May 2020 05:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.091
X-Spam-Level:
X-Spam-Status: No, score=-2.091 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, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov
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 Qi11g8EqvVwD; Mon, 11 May 2020 05:09:40 -0700 (PDT)
Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2120.outbound.protection.outlook.com [40.107.89.120]) (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 25EB73A0A4E; Mon, 11 May 2020 05:09:39 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K/FjfQhD3YKtJPXkUxI+Ky2YqKIwqn4yiPr+Ck7fxmwNdj+m+gXNMyvlM7Rr5ohj8cNuN0NvjlrrN4iRYTS7ZZUiEqFSgptYQuSo2tVFq3yiU/EfqOVwT+pemoN57fAtQ5bo3yplO3/Z80FZ9FjRA5OLx8RDKzCubxP019CMy2P6nhpr6v2u7Gp+PV3G+BHjxlnEvdiGESwij0/iBrfU94XuANknSCN4Jct15C6kL2GkbE51MiE33U5A5wk6LEz0R40MrPHP4ntRAdxxg4z2GPCK++mWjiubdCCUgJVQN5mI4KZjSMDlZ8LRbdPvg4G0M71/1pkOGr8HTPPny7UoRg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qvomrq+JMkCOOaxkRS1CvlssKQBi+sAIdAk9ZuGrJ2E=; b=jdla1rwso3dT/irNFzRTqJINAz2Qd/VxtvGPxu3v1enPa+5lTGFGQXVCgbP+uUJelRkZ0b+cb12YHtbwSIHbJIe53bBmOa88iRwpObRYbazXMG3b7M2cE4UKcaUNPoIAEpTmZs4BFyHORtQsyJB69WBzHvYgifh64rLCUWMtAyb1L3N/j7OBryuD70w3WsxIEJ8Dwd7LTqaOYLM7o43W2CIkTrwJnCXmbbWQnkJi8pmI7Kw2Mzw4TuASEgpBSwSQ2bPJCDAh3ocX3HeBLQg+UYmUxg6jLZJPuul+iItnxizzP/G54/msW9Jdjh4pD69j/FW+RjXMltjCA9q5u1I4oQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qvomrq+JMkCOOaxkRS1CvlssKQBi+sAIdAk9ZuGrJ2E=; b=T8ckHOxkZzCWYPlCtps1dNAsq48tVnhu9SM4iDZgkd5dJj8SKfNb7wJO40f7nyglEQgDDYJN+m6H4rnOiSvDlCuJScs2av9iEgVhDLqYm8Kbb/Tyeh6oKLLJmY7dZo1fr+WgWju4PJ+iL3hRv492btva+esvelijuelUqvgMIoc=
Received: from BY5PR09MB4755.namprd09.prod.outlook.com (2603:10b6:a03:24b::12) by BY5PR09MB5155.namprd09.prod.outlook.com (2603:10b6:a03:24e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.26; Mon, 11 May 2020 12:09:37 +0000
Received: from BY5PR09MB4755.namprd09.prod.outlook.com ([fe80::91d8:62e0:40e6:15e]) by BY5PR09MB4755.namprd09.prod.outlook.com ([fe80::91d8:62e0:40e6:15e%2]) with mapi id 15.20.2979.033; Mon, 11 May 2020 12:09:36 +0000
From: "Dang, Quynh H. (Fed)" <quynh.dang@nist.gov>
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, "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: AQHWJXY75SUMYNJzo0q8VSbsRy8U7aiiv0ST
Date: Mon, 11 May 2020 12:09:36 +0000
Message-ID: <BY5PR09MB4755E58AF9CDF696C0E7F649F3A10@BY5PR09MB4755.namprd09.prod.outlook.com>
References: <07D37E65-0951-49BB-B86E-BD3167ADB352@akamai.com>
In-Reply-To: <07D37E65-0951-49BB-B86E-BD3167ADB352@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=nist.gov;
x-originating-ip: [132.163.219.238]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 0704acc0-eb14-4a2b-a2f0-08d7f5a42c59
x-ms-traffictypediagnostic: BY5PR09MB5155:
x-microsoft-antispam-prvs: <BY5PR09MB515524B4A3C0AD9AE233BE38F3A10@BY5PR09MB5155.namprd09.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 04004D94E2
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 8aZ6pZcaVl+FmsCEmhssBNxMrK225LFjUtR3f4cDCoc0e9X5laFya981CnjrCytWClk7dbhvhaQ5tqVnsUn12wj7e7l/Pfw58A1mH0fmk1SglmfumWJkz84QJae2RY0y0cxSSpsymB7mSUT1Xa8ZQHWu0+s9R1eLdH2UAsTo3wS2RV0hQHf3kZJssU5o01LA/67XIydJ6vwyzNpbYYSES5M2K9GyovnLx0w+w+C9t/zGJqe2N7nyzGHrGq3cesD7cweIZjy5ZlchDpoQXYOK6jGoIMy1mTf9z2AC1rp5FpF6Tg/eWDM88PDRHnn1JdHW7seie7uHdvW864m/9P7tZgiOQRf+JLdSqZV2yMMkT9yPWSZbAooiE2uJIny/ZTWvkXkqQSr1BajzmbYnOFBUJveEApT+E+ZwezfYRtR6TFjFavN5WTgu6SfVwNvboT1k9brocjPcK6mXtam/4HtNpmf4D8Q5JmNje6l+DMb0xlo81Vp5ei6CIUStD1o8QLq/j+s+MWaylA9mw358nEUFLyg7LH3C6Q4lp9fDz0+Xa9xXfPigTBbnCgNOjHZ5brU8fMg4ZZI9g5WkXlVm5yUqXhs/kfVb/iIsyEJy6Hqkw5Q=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR09MB4755.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(376002)(346002)(136003)(39850400004)(366004)(396003)(33430700001)(33656002)(76116006)(45080400002)(316002)(8676002)(5660300002)(8936002)(9686003)(55016002)(26005)(186003)(110136005)(52536014)(6506007)(53546011)(966005)(166002)(7696005)(478600001)(33440700001)(71200400001)(2906002)(66946007)(91956017)(64756008)(66556008)(66476007)(66446008)(83080400001)(19627405001)(86362001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 9K9xb2y8wObYhTkuJ5zuxdxIc7LRED9XPhhpFw6jsMR3yX6j/ZlNdsu1O60UYUxk1tXiFvPlfWbES2KrNhANHGrvQyf3DuKGnbC0JWHEzuxReiB29czErj2r+ggzsJv9A0s6To3efBVjRJrr26Ocf+op9qpIJMULOmQp0zjLw3Cegwzh/7hn/IdcJSmNzcVVHxFjnMooF69mdSlqyxUUOZ/ouIIsQrrkyvXhoyH/e4LZuCRmREg0CHYSS+olKV+f7vXyxM4bLTuuj3zXS0lqrrb4BXzbZIfFfjDntEHORVVhFeCa+vHrhkE7l4hCioptF89kLOEW6AytpkLzn/C2Qzd7WnNvL2Rf+G8E5u/NZEUpUFds3gjbu+5nAD+fktw6CoxImeyJcNRnLV9Qu4rRo1ivRTo3z8NWjp8LMkF0p7z6sw+Ubg6c+/s6ciejqRzAEOFGktejKEbl7w4anAGLbdQc1zcVkTgxj0DaTRvzfKCbsw0qado+s2uN+fW2vDGb
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BY5PR09MB4755E58AF9CDF696C0E7F649F3A10BY5PR09MB4755namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-Network-Message-Id: 0704acc0-eb14-4a2b-a2f0-08d7f5a42c59
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2020 12:09:36.2508 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: LIFs3xU3ka7ibw2Fu8PJLdCr/34dostCPOC2Y4y3tbHMkdt9jDeJk6WvrR9e9El0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR09MB5155
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/k8bNQsG7FGh1RpFDfGp8-LdFf8k>
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: Mon, 11 May 2020 12:09:44 -0000

Hi Rich, Sean and all,

1) Traditionally, a HKDF-Extract is used to extract entropy from a DH type shared secret. However, the first HKDF-Extract in the key schedule takes a PSK instead of a DH shared secret.

We don't see security problems with this instance in TLS 1.3. NIST requires the PSK to have efficient amount of entropy (to achieve a security strength required by NIST) when it is externally generated. When it is externally generated, one of NIST's approved random bit generation methods in SP 800-90 series must be used.

When the PSK is a resumption key, then its original key exchange and its key derivation function(s) must meet the security strength desired/required for the PSK.

NIST plans to allow/approve the function in SP 800-133r2, Section 6.3, item # 3 on pages 22 and 23: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r2-draft.pdf

2) Traditionally, HKDF is extract-then-expand. However, in TLS 1.3, we have extract-then-multiple expands.

We don't see security problems for this new version of HKDF as specified in TLS 1.3.  NIST plans to approve a general method for this approach in SP 800-56C revision 2, section 5.3: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2-draft.pdf

NIST plans to handle the issues above that way to avoid repeating the work when one or both of the same HKDF instances or new variant(s) for one or both of them is/are used in different application(s).

The other KDFs are already compliant with NIST's existing KDFs.

Regards,
Quynh.
Recommendation for Key-Derivation Methods in Key-Establishment Schemes<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2-draft.pdf>
23 . Draft NIST Special Publication 800-56C 24 . Revision 2 25 Recommendation for Key-Derivation 26 . Methods in Key-Establishment Schemes 27 . 28 . 29 Elaine Barker 30 Lily Chen 31 Computer Security Division 32 . Information Technology Laboratory
nvlpubs.nist.gov

________________________________
From: Cfrg <cfrg-bounces@irtf.org> on behalf of Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org>
Sent: Friday, May 8, 2020 4:21 PM
To: tls@ietf.org <tls@ietf.org>rg>; cfrg@ietf.org <cfrg@ietf.org>
Subject: [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)

If you don’t care about FIPS-140, just delete this message, and avoid the temptation to argue how bad it is.

NIST SP 800-56C (Recommendation for Key-Derivation Methods in Key-Establishment Schemes) is currently a draft in review. The document is at https://csrc.nist.gov/publications/detail/sp/800-56c/rev-2/draft  Email comments can be sent to 800-56C_Comments@nist.gov with a deadline of May 15.  That is not a lot of time.  The NIST crypto group is currently unlikely to include HKDF, which means that TLS 1.3 would not be part of FIPS. The CMVP folks at NIST understand this, and agree that this would be bad; they are looking at adding it, perhaps via an Implementation Guidance update.

If you have a view of HKDF (and perhaps TLS 1.3), I strongly encourage you to comment at the above address.  Please do not comment here. I know that many members of industry and academia have been involved with TLS 1.3, and performed security analysis of it. If you are one of those people, *please* send email and ask the NIST Crypto Team to reconsider.

Thank you.
        /r$



_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg&amp;data=02%7C01%7Cquynh.dang%40nist.gov%7C6ba71a06d50f41e6582508d7f38d7d80%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637245661358887556&amp;sdata=5DEzorMNakxeh%2Bkb4wYJ00QxyRmcXbsDFm7wlVw9iig%3D&amp;reserved=0