Re: [Cfrg] TLS PRF security proof?

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 09 July 2014 15:28 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 111B41A0AF3 for <cfrg@ietfa.amsl.com>; Wed, 9 Jul 2014 08:28:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 E6oAenSrdf2a for <cfrg@ietfa.amsl.com>; Wed, 9 Jul 2014 08:28:28 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A5FE1A0AF2 for <cfrg@irtf.org>; Wed, 9 Jul 2014 08:28:28 -0700 (PDT)
Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s69FSOwv095734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Jul 2014 08:28:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90]
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CALCETrVG9Ltf=9x64mOScorLCUPZNtr1XF6rkfpgzT2GDiwi+g@mail.gmail.com>
Date: Wed, 09 Jul 2014 08:28:22 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A60ED12-70B4-4CBF-B31E-3D5DDA7DC7EA@vpnc.org>
References: <20140709125829.22319253.16811.16396@certicom.com> <CALCETrVG9Ltf=9x64mOScorLCUPZNtr1XF6rkfpgzT2GDiwi+g@mail.gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/SnolnjMHPeFqrvHbPOAPJIv8eqY
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
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:28:29 -0000

On Jul 9, 2014, at 8:18 AM, Andy Lutomirski <luto@amacapital.net> wrote:

> I can't speak for the TLS WG, but from my own perspective, I have
> three problems with HDKF:
> 
> 1. HKDF is parametrized by a hash.  What hash should people use?

Any one that has no known weakening of preimage resistance. That is: nearly any of them.

> (Hence my suggestion of using combiners -- changing the PRF in an
> existing protocol is a real PITA and might not even be possible
> without introducing security holes.)

Adding more choices makes interoperability less likely. In real-world protocols, excellent interoperability with almost-perfect security is *much* better than good interoperability with perfect security.

> 2. The RFC didn't make the security properties clear to me.  For
> example, protocols should stick nonces into the salt.  Oh, wait, they
> shouldn't stick nonces into the salt without care.  

Can you justify that second sentence with anything from RFC 5869? In fact, it says the opposite:

   Ideally, the salt value is a random (or pseudorandom) string of the
   length HashLen.  Yet, even a salt value of less quality (shorter in
   size or with limited entropy) may still make a significant
   contribution to the security of the output keying material; designers
   of applications are therefore encouraged to provide salt values to
   HKDF if such values can be obtained by the application.

> Can I use multiple
> "info" values to safely extract key material and publish it?

Yes. Can you point at something in the RFC that indicates any different?

> 3. (Only relevant to hashes using MD construction) My understanding of
> HMAC is that it's secure against generic attacks on MD hashes if the
> key is secret and unpredictable.  HKDF doesn't necessarily use a
> secret, unpredictable key for HMAC.  Is HKDF-SHA-1 insecure as a
> result?  What about HKDF-SHA-512 against an adversary with unlimited
> precomputation power?

For the discussion at hand, the key is secret and unpredictable.

--Paul Hoffman