Re: [Cfrg] TLS PRF security proof?

Dan Brown <dbrown@certicom.com> Wed, 09 July 2014 15:27 UTC

Return-Path: <dbrown@certicom.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099751A0AF3 for <cfrg@ietfa.amsl.com>; Wed, 9 Jul 2014 08:27:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 gIaSuW13TzmK for <cfrg@ietfa.amsl.com>; Wed, 9 Jul 2014 08:27:29 -0700 (PDT)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 28ED11A0AF2 for <cfrg@irtf.org>; Wed, 9 Jul 2014 08:27:28 -0700 (PDT)
Received: from xct107cnc.rim.net ([10.65.161.207]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 09 Jul 2014 11:27:28 -0400
Received: from XCT114CNC.rim.net (10.65.161.214) by XCT107CNC.rim.net (10.65.161.207) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 9 Jul 2014 11:27:27 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT114CNC.rim.net ([::1]) with mapi id 14.03.0174.001; Wed, 9 Jul 2014 11:27:26 -0400
From: Dan Brown <dbrown@certicom.com>
To: "'cfrg@irtf.org'" <cfrg@irtf.org>
Thread-Topic: [Cfrg] TLS PRF security proof?
Thread-Index: Ac+a3pfHyneQDJEcQp6NTm7HFwn/FgAJR3CAAAXgkgAAG3DqQA==
Date: Wed, 09 Jul 2014 15:27:26 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF5CB6A3D@XMB116CNC.rim.net>
References: <810C31990B57ED40B2062BA10D43FBF5CB648D@XMB116CNC.rim.net> <CALCETrVekyPJeUdEReZ8L8zqrP5UOgHR4+MkYtNt2FFFdmMVew@mail.gmail.com> <b2b7a90843f86ec8828beec30560f3b8.squirrel@www.trepanning.net>
In-Reply-To: <b2b7a90843f86ec8828beec30560f3b8.squirrel@www.trepanning.net>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.252]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0029_01CF9B68.C2F27F50"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/QGMMgXMh-mTSqLZgvMHRohYpKcE
Subject: Re: [Cfrg] TLS PRF security proof?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jul 2014 15:27:31 -0000

Oops, I see now that the the TLS PRF is based on the key expansion phase of
HKDF!  This is called PRF* in the Krawczyk's eprint.  Maybe the TLS draft
should cite the HKDF paper.

Anyway, Section 7 of the HKDF eprint says the "feedback mode" design of PRF*
is heuristic, and is more conservative than a simpler counter mode.

So, despite my mix-up, my questions still stand: Is PRF* proven secure? How
failsafe is it?

> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@lounge.org]
> Sent: Tuesday, July 08, 2014 6:12 PM
> To: Andy Lutomirski
> Cc: Dan Brown; cfrg@irtf.org
> Subject: Re: [Cfrg] TLS PRF security proof?
> 
> 
> 
> On Tue, July 8, 2014 12:24 pm, Andy Lutomirski wrote:
> > On Tue, Jul 8, 2014 at 12:19 PM, Dan Brown <dbrown@certicom.com> wrote:
> >>
> >> Dear CFRG list,
> >>
> >>
> >>
> >> Is there a published security proof for the current TLS PRF in the
> >> draft TLS 1.3?
> >>
> >
> > Would it be useful if CFRG were to publish a recommended PRF?  Perhaps
> > something using a modern hash function combiner using (HMAC-)SHA-512
> > and either SHA-3 or something from the Salsa/ChaCha family as the
> > base?
> 
>   What about RFC 5869? http://eprint.iacr.org/2010/264 describes the
design
> rationale which is more than what TLS PRF has (which, to me, seems a bit
ad
> hoc).
> 
>   regards,
> 
>   Dan.
>