Re: [TLS] HKDF

Hugo Krawczyk <hugo@ee.technion.ac.il> Wed, 25 March 2015 15:27 UTC

Return-Path: <hugokraw@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 3492C1A87F1 for <tls@ietfa.amsl.com>; Wed, 25 Mar 2015 08:27:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 R3v-n1f5o3gR for <tls@ietfa.amsl.com>; Wed, 25 Mar 2015 08:27:20 -0700 (PDT)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::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 3722A1A87BB for <tls@ietf.org>; Wed, 25 Mar 2015 08:27:20 -0700 (PDT)
Received: by labe2 with SMTP id e2so22752246lab.3 for <tls@ietf.org>; Wed, 25 Mar 2015 08:27:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=/a/d5Ky7uUFM34jTGx5sy2Wj7bLjPpAPsJfaAiTbPs4=; b=dqFKjwX9/7CRfO5tEseLKyfJptU/30k4gwA8ongTlqR6bdxDdBnHLZkWHHqdhWR87b /epPMbxSV2VAbs1JqNQTYSRbAzNB/wbAsj96hYbzcfZCUygAoMBTdYhKjcGsvb0ONyKk Koxx5HM6NYR8IzGFWikIAjCbNWbb/tc2q2vHh5iGs4NKq1UYi2MKe1Oj9eJYz5d4HOaC wpNpsfibQfNpYvhutL99RVZrzmVsa8CnAh75cHxJWQXtEAmR9Ketwevr1IUaEY2vEClw SLaxJ0dh1MZsDKUj8+FKZOLW5j+aJ6oPU3fw89YY+ZHp8i7rxR+Pw/AX9zevbzrHiai4 K7Fw==
X-Received: by 10.112.170.100 with SMTP id al4mr9130224lbc.42.1427297238712; Wed, 25 Mar 2015 08:27:18 -0700 (PDT)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by 10.25.78.9 with HTTP; Wed, 25 Mar 2015 08:21:38 -0700 (PDT)
In-Reply-To: <CAKUk3buuP+=AA0kLF9VodASVfQSYGZq016sqcbe8eoNJRKZxGA@mail.gmail.com>
References: <CABcZeBPa3j+EfMkPik7r5G-qcBpYkXTFWwYwuCeE38mFjUwpJw@mail.gmail.com> <7FA320AE-B9C2-412D-B84B-DB4CAB05B325@gmail.com> <5510FDC8.1060702@brainhub.org> <358E3F82-0777-42A1-AA75-F31AA3C2103B@gmail.com> <20150324121632.GA28552@LK-Perkele-VII> <CAKUk3buuP+=AA0kLF9VodASVfQSYGZq016sqcbe8eoNJRKZxGA@mail.gmail.com>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Wed, 25 Mar 2015 11:21:38 -0400
X-Google-Sender-Auth: svB15NeFFe_QRRJCrFX-IyWTlec
Message-ID: <CADi0yUPG7Ac_V69__M1gQd_8fkaj=0-HEz=oL1mzTSjQjhJrBw@mail.gmail.com>
To: Andrey Jivsov <crypto@brainhub.org>
Content-Type: multipart/alternative; boundary="001a11c23686e7085505121e88fe"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/7Au4xv9tdSpFu0AixkQ8LafIugU>
Cc: "tls@ietf.org" <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: Wed, 25 Mar 2015 15:27:23 -0000

On Wed, Mar 25, 2015 at 11:02 AM, Andrey Jivsov <crypto@brainhub.org> wrote:

> A problem with this is additional options.
>

​What are the additional options? ​

​You use the defined hash function.

> There is no problem with HKDF that I see other than it relaxes assumptions
> on hash functions,
>
​Relaxing assumptions is not a problem but rather a good thing: It means
that you need to assume less from the hash function, e.g. not having a
scheme broken if collisions are found on that function. In some cases we
still need to model the hash function as a random oracle but we minimize
these cases and only need to assume it for the compression function not the
iterated one (the iterated function contradicts the random oracle model
just by virtue of extension attacks).
​


> but we would not be using such weak hash functions in TLS.
>
​I am not sure what you mean by this - the problem is that we never know
how weak a hash function is until we know... (i.e someone breaks it).
​


> HKDF is probably viewed as an insurance. Please note that the benefits
> will be bound by the "ad-hoc" methods to process entropy into private keys.
>

​That's true, but these ad-hoc methods have a better analytical basis than
just using non-uniform keys to key directly a PRF.
​


> One idea for meaningful reduction of complexity in TLS is if we could
> switch to cipher-based KDF.
>
​That's for the WG to decide but the results we have for the extraction
properties of block-cipher based PRFs are much weaker.
​


> We countinue to use hash for digital signatures, controlled by the
> signature extension.
>
An AEAD cipher is required and has the MAC method internal to them.
> Therefore, this would drop hash functions from the ciphersuites.
>
​​​You need hash functions for generating the session hash, even if you
don't use a digital signature at all.

Hugo
​


> On Mar 24, 2015 7:16 AM, "Ilari Liusvaara" <ilari.liusvaara@elisanet.fi>
> wrote:
>
>> On Tue, Mar 24, 2015 at 06:39:43AM -0500, Yoav Nir wrote:
>> >
>> > > On Mar 24, 2015, at 1:01 AM, Andrey Jivsov <crypto@brainhub.org>
>> wrote:
>> > >
>> > > 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?
>>
>> Or even special Suite B ciphersuites. I think there are only 2 of
>> those.
>>
>> - ECDHE/P-256, ECDSA/P-256, AES-128-GCM, SHA-256
>> - ECDHE/P-384, ECDSA/P-384, AES-256-GCM, SHA-384
>>
>> The basic idea being: They who care can implement that.
>>
>>
>> -Ilari
>>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>