Re: [TLS] HKDF

Hugo Krawczyk <hugo@ee.technion.ac.il> Thu, 26 March 2015 02:08 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 1A2A21A1C02 for <tls@ietfa.amsl.com>; Wed, 25 Mar 2015 19:08:29 -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 E4NHzXSCIhjl for <tls@ietfa.amsl.com>; Wed, 25 Mar 2015 19:08:27 -0700 (PDT)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (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 DABC11A1DE1 for <tls@ietf.org>; Wed, 25 Mar 2015 19:08:26 -0700 (PDT)
Received: by lbcgn8 with SMTP id gn8so30930727lbc.2 for <tls@ietf.org>; Wed, 25 Mar 2015 19:08:25 -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=Z/SRhoW3QsxQFUOpYsk/moxFKhN1qTyHPqxEReDfdEs=; b=MkCnpOqjkM0dJrlukmsaqAr6KeA//DQubnjoTUMlFaH72CY58NfThOV8DY5kMAN4vv XGl/9rHKvjMGc7Cpj5COdfMHOT5GpJRRrCqPO1pfAWEJ+D9tXvh34OpwJrsqccn/EtOC km5Rmjt2eqdrsZr+uFcHVcbh/sfsnyS/zebgA6Ne2DDhTamGQxOZNZGzI65GJhhehJo2 swtWTDKgTqXnGi3EcY19Imh+kKvgz8oY0yVQL6aCUD7I2l0poo8xrBwgFcC7mOANjokK L2LfHg4fRw7aXfmaBv0fd5Ru/Q+MPMTHHdLt+zKVG2BB6xRx+h80dSCZiIJMz5zmFzfO FDwQ==
X-Received: by 10.152.87.144 with SMTP id ay16mr11422618lab.10.1427335705402; Wed, 25 Mar 2015 19:08:25 -0700 (PDT)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by 10.25.78.9 with HTTP; Wed, 25 Mar 2015 19:07:55 -0700 (PDT)
In-Reply-To: <1427297776.4885.47.camel@redhat.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> <CADi0yUPG7Ac_V69__M1gQd_8fkaj=0-HEz=oL1mzTSjQjhJrBw@mail.gmail.com> <1427297776.4885.47.camel@redhat.com>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Wed, 25 Mar 2015 21:07:55 -0500
X-Google-Sender-Auth: 9VCmSCSC32R_1v2YcPbVy5ifVVM
Message-ID: <CADi0yUOAcEPO2XafSwx0+FY4z=AmPZctA0rfQ8HbV5s=296vGg@mail.gmail.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Content-Type: multipart/alternative; boundary="001a11c235e6b224060512277d0e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/m4de4uhTcDijM8zO1QyMJf3u6Mo>
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: Thu, 26 Mar 2015 02:08:29 -0000

On Wed, Mar 25, 2015 at 11:36 AM, Nikos Mavrogiannopoulos <nmav@redhat.com>
wrote:

> On Wed, 2015-03-25 at 11:21 -0400, Hugo Krawczyk wrote:
>
>
> >         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.
>
> I'm not sure whether the WG should even decide on replacing the KDF or
> the main protocols used. That was certainly a non-goal for TLS 1.3 and
>

​
There is an explicit goal of supporting forward secrecy and 0-RTT.
Both require changes to the protocol, in particular the latter requires
introducing server's (semi) static DH keys and an authentication mode that
cannot be solely based on signatures hence necessarily departing from
previous TLS versions. You could add support for the above elements as a
patch/addition to the protocol but even then you would need a review of the
new cryptographic elements and their interaction with the old ones (which
may be trickier to analyze than a well-formed uniform protocol).

Hugo
​


> is a cryptographic decision which is not the expertise of this group.
> For such decisions, and even simpler (see Salsa20, ChaCha cipher
> addition) this working group delegated these decisions to CFRG, and I
> believe this should also be done now if we go the path of replacing
> core TLS structure.
>
> regards,
> Nikos
>
>
>