Re: [TLS] HKDF

Yoav Nir <ynir.ietf@gmail.com> Tue, 24 March 2015 11:39 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89D91A8993 for <tls@ietfa.amsl.com>; Tue, 24 Mar 2015 04:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 9atuKQeDx_V4 for <tls@ietfa.amsl.com>; Tue, 24 Mar 2015 04:39:45 -0700 (PDT)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 650841A898F for <tls@ietf.org>; Tue, 24 Mar 2015 04:39:45 -0700 (PDT)
Received: by oiag65 with SMTP id g65so165061976oia.2 for <tls@ietf.org>; Tue, 24 Mar 2015 04:39:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3Wc5bjQdu+8cyRJ6PXYbQPkPruREGjHpikSgmnVwE+E=; b=OBbCq/6No83FlMnrJBpPbUvleWgd8B7UTIm2EqJbpwuZkO3M3mXOjh0Ba2HYordSMh v7CcMc0D3IhuiY9Ks2b5pFRh6UtCpUxU33mdSe6ID89oujjJSc8WHVDW/CJOJ084rxvu 92/7jesWudtmtF8WhEL3olaNK6PSUVvDVDWtfKUrX1bN6wDTs6ai985lIjlzVvqKXYzZ OcEbFHBivV+22d1BIIHtdzMC+WFlhq5TNsXo6x2Ew7VtQi2ZeIJggi8DdCZAFchvY8JI ePrQHwhg4aYaKq/oCkOIdWvPg/yq0kx2TVmXUGhFMh9I2+fxBO/cDo5kda0rp9m005k4 BsTw==
X-Received: by 10.182.199.70 with SMTP id ji6mr2909704obc.3.1427197184868; Tue, 24 Mar 2015 04:39:44 -0700 (PDT)
Received: from [10.111.111.122] ([173.200.48.34]) by mx.google.com with ESMTPSA id f133sm2033338oia.8.2015.03.24.04.39.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Mar 2015 04:39:43 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <5510FDC8.1060702@brainhub.org>
Date: Tue, 24 Mar 2015 06:39:43 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <358E3F82-0777-42A1-AA75-F31AA3C2103B@gmail.com>
References: <CABcZeBPa3j+EfMkPik7r5G-qcBpYkXTFWwYwuCeE38mFjUwpJw@mail.gmail.com> <7FA320AE-B9C2-412D-B84B-DB4CAB05B325@gmail.com> <5510FDC8.1060702@brainhub.org>
To: Andrey Jivsov <crypto@brainhub.org>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/7Z56_dPwc6cXv4Y5hWTkKo0yKkc>
Cc: tls@ietf.org
Subject: Re: [TLS] HKDF
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 24 Mar 2015 11:39:47 -0000

> On Mar 24, 2015, at 1:01 AM, Andrey Jivsov <crypto@brainhub.org> wrote:
> 
> On 03/23/2015 09:58 PM, Yoav Nir wrote:
>>> On Mar 23, 2015, at 9:19 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>>> 
>>> As I mentioned in a previous message [0] during the interim we discussed
>>> moving from the TLS PRF to HKDF [RFC5869].
>>> 
>>> The general sentiment was:
>>> 
>>> - Move to HKDF
>>> - Specify both SHA-256 and SHA-384 (the latter being required for
>>>   Suite B)
>>> 
>>> This is also the time when we would want to look at adjusting
>>> the key expansion to separate keys and IVs (assuming we still
>>> have IVs).
>>> 
>>> Please use this thread to discuss this topic.
>>> 
>> OK, since you’re proposing to abandon the current TLS PRF:
>> 
>> 1. Why? What is wrong with the TLS PRF, and
>> 2. If we’re changing it, why not to a fast PRF such as blake2?
>> 
>> Yoav
>> 
> I am somewhat sympathetic to this sentiment. Please also consider that KDFs and related processes are standardized by NIST. E.g.:
> 
> 1. NIST-prescribed way to do KDF, SP 800 108A (it includes HMAC KDF for key expansion)
> 
> 2. NIST DH schemes include KDF, SP 800-56A rev2 (HKDF paper of 2010 criticizes the first revision; rev 2 is dated 2015)
> 
> 3. NIST grandfathered TLS KDF in SP 800-135.
> 
> 4. A very similar SP 800-56C that documents Extraction-then-Expansion, where expansion is done with #1 (credits Hugo Krawczyk, among others)
> 
> Please note that at least some of these can be FIPS 140 tested (in particular, TLS PRF). Suite B expects the use of these approved KDFs.
> 
> While NIST is perhaps too prolific with these, I feel that we should look into standard KDFs. There are test vectors, verifications systems, existing implementations…

If such a KDF is needed for Suite-B, then it makes sense for Suite-B ciphersuites - the ones with ECDSA, P-256 or P-384 for ECDHE, and AES-GCM.  

Why not include a different PRF in those suites that have non-NIST-approved algorithms such as ChaCha20, Curve25519, and whatever signature scheme CFRG are going to recommend?

Yoav