Re: [TLS] HKDF

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Thu, 26 March 2015 07:16 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
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 DCE841ACDD3 for <tls@ietfa.amsl.com>; Thu, 26 Mar 2015 00:16:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 fu_GU7JyY5zM for <tls@ietfa.amsl.com>; Thu, 26 Mar 2015 00:16:06 -0700 (PDT)
Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8C91A7002 for <tls@ietf.org>; Thu, 26 Mar 2015 00:16:05 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 6AD6481856; Thu, 26 Mar 2015 09:15:59 +0200 (EET)
Date: Thu, 26 Mar 2015 09:15:59 +0200
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Hugo Krawczyk <hugo@ee.technion.ac.il>
Message-ID: <20150326071559.GA6108@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> <CAKUk3buuP+=AA0kLF9VodASVfQSYGZq016sqcbe8eoNJRKZxGA@mail.gmail.com> <CADi0yUPG7Ac_V69__M1gQd_8fkaj=0-HEz=oL1mzTSjQjhJrBw@mail.gmail.com> <1427297776.4885.47.camel@redhat.com> <CADi0yUOAcEPO2XafSwx0+FY4z=AmPZctA0rfQ8HbV5s=296vGg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CADi0yUOAcEPO2XafSwx0+FY4z=AmPZctA0rfQ8HbV5s=296vGg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/rHBPrLuh37iJ_OG8Yy2xhnDIi0E>
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 07:16:09 -0000

On Wed, Mar 25, 2015 at 09:07:55PM -0500, Hugo Krawczyk wrote:
> 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).

Well, these changes to "unify" the key exchange completely change how
to the key exchange works, and need to completely redo any security
analysis. This is nasty for multiple reasons:
a) The scope of analysis is very broad (there have been a number of
   "TLS proven secure" papers that don't prove TLS secure, due to
   insufficient scope)
b) The changes to proposed look to make it much harder to analyze,
   even if 0RTT is assumed unsupported
c) When 0RTT is added, I don't see how the changes make the interaction
   any easier to analyze.


-Ilari