Re: [TLS] HKDF

Andrey Jivsov <crypto@brainhub.org> Wed, 25 March 2015 15:02 UTC

Return-Path: <andrey@brainhub.org>
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 4047A1B29CA for <tls@ietfa.amsl.com>; Wed, 25 Mar 2015 08:02:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 E-2PIPaodIzA for <tls@ietfa.amsl.com>; Wed, 25 Mar 2015 08:02:33 -0700 (PDT)
Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (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 B0FC31A86E4 for <tls@ietf.org>; Wed, 25 Mar 2015 08:02:32 -0700 (PDT)
Received: by wgdm6 with SMTP id m6so30959747wgd.2 for <tls@ietf.org>; Wed, 25 Mar 2015 08:02:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MN3WNqPd7Qt2fG7BWQvunNlcm60w/c7FDIUfo5pjJh8=; b=VJhIzni9erVJDdWka1/JXonWh0sfoR7VTneceoCKTq/46nvG6aCQQIjbiutQae/4JZ bngMPGRj0mvQmvaCn17WfOoJI8khnGjtSDpv5qsUwUsU3PLE0Z1rGG8LAenwHa38EFqd ThGwJFqDd91Z/NAA0di1KaSCB8TO6OJHFpsxQtXwAfmlFOxwHvGHxHFSeovkoBihA+BR KZ1oIPuRkvvStlYNujOSHxQwb7TdLGugpnOyRa6KYo6saw+79oak5qzbcHqjqG0lftlh 2trns8oveRhVG6GiowHcO+nQXkesYZSdCOzIUhDw8G1XnlagpWdPoaFtRFulswwqM9u8 kZoQ==
X-Gm-Message-State: ALoCoQmo7nGafetmz/2nThjLZ7Obt46fRu3Og639cBEIytaZOggJ3y2V2aqr1YSAYmo6lTdkbZCl
MIME-Version: 1.0
X-Received: by 10.194.63.172 with SMTP id h12mr18725922wjs.48.1427295751022; Wed, 25 Mar 2015 08:02:31 -0700 (PDT)
Sender: andrey@brainhub.org
Received: by 10.27.14.66 with HTTP; Wed, 25 Mar 2015 08:02:30 -0700 (PDT)
X-Originating-IP: [31.133.162.114]
Received: by 10.27.14.66 with HTTP; Wed, 25 Mar 2015 08:02:30 -0700 (PDT)
In-Reply-To: <20150324121632.GA28552@LK-Perkele-VII>
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>
Date: Wed, 25 Mar 2015 08:02:30 -0700
X-Google-Sender-Auth: bzXUn5PawlDqRsuat0BZmP6fT3c
Message-ID: <CAKUk3buuP+=AA0kLF9VodASVfQSYGZq016sqcbe8eoNJRKZxGA@mail.gmail.com>
From: Andrey Jivsov <crypto@brainhub.org>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Content-Type: multipart/alternative; boundary="047d7ba9780a3ac53505121e3033"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/sZRQHzTT06HOpoWjoW1Bwd0LckA>
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: Wed, 25 Mar 2015 15:02:37 -0000

A problem with this is additional options.

There is no problem with HKDF that I see other than it relaxes assumptions
on hash functions, but we would not be using such weak hash functions in
TLS. 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.

One idea for meaningful reduction of complexity in TLS is if we could
switch to cipher-based KDF. 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.
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
>