Re: [Cfrg] TLS PRF security proof?
Hugo Krawczyk <hugo@ee.technion.ac.il> Thu, 10 July 2014 22:10 UTC
Return-Path: <hugokraw@gmail.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 1E8391B27F7 for <cfrg@ietfa.amsl.com>; Thu, 10 Jul 2014 15:10:13 -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 Af_XmWajhMnr for <cfrg@ietfa.amsl.com>; Thu, 10 Jul 2014 15:10:11 -0700 (PDT)
Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D75A71B27F3 for <cfrg@irtf.org>; Thu, 10 Jul 2014 15:10:10 -0700 (PDT)
Received: by mail-ob0-f176.google.com with SMTP id wo20so266223obc.7 for <cfrg@irtf.org>; Thu, 10 Jul 2014 15:10:10 -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:content-type; bh=bzLP9cYsl41VnPvoTVmQo4HjLQCqRGvAhBec+C+Jlxk=; b=SRCtQ4BwBbsxKWEXHnJ0Y9450TGtEqZoloiIaXU4ALBsxI1JckULSpCpFoudhgyu1B Pbo5NjHkzky3dRrMtLlR8N8gyxLPiuN1tSVMUtOV0WQBLXY2zWmaBQhNEtrmR/0N4Ldd HsiBwE4y5eesGSeAmlh+mJqEhMnC3ZxXTAIVFRiZC3RHmQN+HZOCyu7BrGihK1QNE0P7 K+padjhhRpkvMPpvqPQCStB1XeNxoSm/TGIG6TSVN0kGPXRWdI/mmGD6+UxA8pB10X6P IIwXrmM3JsEtr7wCgqcF+g6PEXXtUh5x6fE+lud0/Rnfwo7H0lxOV2iHOkB96dSczheE hZMA==
X-Received: by 10.60.83.177 with SMTP id r17mr58893265oey.53.1405030210124; Thu, 10 Jul 2014 15:10:10 -0700 (PDT)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by 10.202.192.85 with HTTP; Thu, 10 Jul 2014 15:09:39 -0700 (PDT)
In-Reply-To: <53BE761A.9000709@rwth-aachen.de>
References: <20140709125829.22319253.16811.16396@certicom.com> <CALCETrVG9Ltf=9x64mOScorLCUPZNtr1XF6rkfpgzT2GDiwi+g@mail.gmail.com> <6A60ED12-70B4-4CBF-B31E-3D5DDA7DC7EA@vpnc.org> <CALCETrXMZZVbF3tzZm0PfuKQ0h8mUoj7XcWgcJMNMgTuEp1+dg@mail.gmail.com> <CALCETrW7JUbJTJAY3UWf6EpXWc5ij+xy3fzWXE8+-xtpsLG7CQ@mail.gmail.com> <CACsn0c=9PuGD8p0hM6LUJKFMN_eP=UtGQN38y6DW9rsQsy1PLQ@mail.gmail.com> <CALCETrWo+gvVkL8P4Lw-ZtuTfu=L_q5+h9zcdpPyZvB5-FE0vg@mail.gmail.com> <CACsn0cmL6DcbynZkDOZST7-Voq+n217awx737dv7oy5VYWFDyg@mail.gmail.com> <CALCETrX5gJdQZATrzOrXtw_M4hc320yUi_HJPuexJORUuUw07g@mail.gmail.com> <53BE761A.9000709@rwth-aachen.de>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Thu, 10 Jul 2014 18:09:39 -0400
X-Google-Sender-Auth: pzYy4GczoIfGSdBqoxqdFeHX4pE
Message-ID: <CADi0yUNyU+bMTTPVm-1WXL=TQM4Fd1VFSrPOPnJ-zXXtWosvoQ@mail.gmail.com>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="089e01182a0c92c26504fdde16cb"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/FWo3cD8bjVYODQS8xNwPWxyy6m0
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: Thu, 10 Jul 2014 22:10:13 -0000
Let me provide some clarifications regarding this discussion. If I understand correctly, Dan Brown's original posting referred to the TLS PRF and its use of a feedback mode. Later postings started discussing HKDF which uses this feedback mode but only as a component of a more general functionality, namely, key derivation. The crucial difference between KDFs and PRFs is that the latter are used to expand a strong cryptographic key into several keys while KDFs assume that you start with keying material of "sufficient entropy" but not contained in the form of a short uniform (or pseudo-random) key. Thus, HKDF works in two stages: a first stage that "extracts" a strong cryptographic key from the input entropy and a second stage where this key is expanded into more (cryptographically strong) keys using a PRF. HKDF is defined in RFC 5869 which contains limited design and use rationale but which is backed by a detailed article explaining such rationale: http://eprint.iacr.org/2010/264. The intention of the paper was to be written so that it contains the formal treatment a mathematical cryptographer expects but also have intuitive English discussions for the less formalist reader (actually, most of the math background for the paper belongs to prior work). So I would encourage people interested in the discussion in this thread to take a look at the paper; it should answer some of the questions raised here such as the role of salt, source independence, etc.). In particular, the paper contains a short section on the rationale of using feedback mode for the PRF part and its advantage over counter mode (answering one of the points raised by Dan Brown). Indeed, I argue that while counter mode is more natural it is also more vulnerable to future weaknesses (*). It is also worth noting that HKDF adds an increasing counter to the feedback iterations that is not part of the TLS definition and was added to defend against (theoretical) hash cycles. I would recommend that any revision of TLS that changes its key derivation adopts HKDF as defined in RFC 5869. A general comment to address some of the more specific issues raised in this discussion: The basic design goal of HKDF is to serve as a multi-purpose design. One that works in all key derivation scenarios (from whitening the output of a physical RNG to extracting randomness from pools of entropy to deriving keys in key exchange protocol) and with different assumptions on the underlying cryptographic hash functions. In particular, confining the use of idealized assumptions (e.g., random oracle) or even collision resistance to the minimum necessary. The important point is that you get the benefits of the design without having to customize it on a per-use basis. Hugo (*) This PRF mode of operation (introduced in the early design of IKEv1, from which it found its way to TLS via SSLv3) was "inspired" by the early weaknesses of MD5 (Dobbertin work). I thought at the time that we better design safegueards to protect against future weaknesses of our beloved functions. I believe we should stick to that principle.
- [Cfrg] TLS PRF security proof? Dan Brown
- Re: [Cfrg] TLS PRF security proof? Andy Lutomirski
- Re: [Cfrg] TLS PRF security proof? Igoe, Kevin M.
- Re: [Cfrg] TLS PRF security proof? Dan Harkins
- Re: [Cfrg] TLS PRF security proof? Peter Gutmann
- Re: [Cfrg] TLS PRF security proof? Paterson, Kenny
- Re: [Cfrg] TLS PRF security proof? Dan Brown
- Re: [Cfrg] TLS PRF security proof? Andy Lutomirski
- Re: [Cfrg] TLS PRF security proof? Dan Brown
- Re: [Cfrg] TLS PRF security proof? Paul Hoffman
- Re: [Cfrg] TLS PRF security proof? Andy Lutomirski
- Re: [Cfrg] TLS PRF security proof? Andy Lutomirski
- Re: [Cfrg] TLS PRF security proof? Watson Ladd
- Re: [Cfrg] TLS PRF security proof? Andy Lutomirski
- Re: [Cfrg] TLS PRF security proof? Watson Ladd
- Re: [Cfrg] TLS PRF security proof? Andy Lutomirski
- Re: [Cfrg] TLS PRF security proof? Jakob Breier
- Re: [Cfrg] TLS PRF security proof? Hugo Krawczyk
- Re: [Cfrg] TLS PRF security proof? Watson Ladd
- Re: [Cfrg] TLS PRF security proof? Hugo Krawczyk