Re: [Cfrg] TLS PRF security proof?

Watson Ladd <watsonbladd@gmail.com> Thu, 10 July 2014 01:52 UTC

Return-Path: <watsonbladd@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 61AF41A0193 for <cfrg@ietfa.amsl.com>; Wed, 9 Jul 2014 18:52:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 jh9LMo2eRBzX for <cfrg@ietfa.amsl.com>; Wed, 9 Jul 2014 18:52:51 -0700 (PDT)
Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391501A0180 for <cfrg@irtf.org>; Wed, 9 Jul 2014 18:52:51 -0700 (PDT)
Received: by mail-wg0-f49.google.com with SMTP id a1so4954566wgh.32 for <cfrg@irtf.org>; Wed, 09 Jul 2014 18:52:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1tXj0e0J5r0j42SMudNjgalhnqtXIYz2Ky6z77tHpbI=; b=Rm5RBHHA4acGC1I/EW0mGOHHaMYyMV5ApoeOa0B2noh3VYAJ0Avi0qlwVPkW/MWGgQ GpMco3NR7sZxZ1SHQsLRKbXF2sJv0nwGY7lLnp1bf+nTexpD29SRq3Q3WjC4fW/+07UK JDKbY+ofsjtZI7/s7D9Z8pAhV/0FjCQbMzj7q/oPquDNyyqiE0JKMy5HGyjYkyhvNyV1 Pe9T9SolN4FSaco5CljVW8H4zBjSIKRIXvbm+JTGqZ2/CXlREh2g0XVg9XeDFdvM6Hn0 5gAZmTKSlwkFPDffsAsydYBG1C3hOPp8xlwByV4wpPhdqHANoR39/K7px+bS0grF7zbC ToAQ==
MIME-Version: 1.0
X-Received: by 10.194.82.198 with SMTP id k6mr52641500wjy.10.1404957169888; Wed, 09 Jul 2014 18:52:49 -0700 (PDT)
Received: by 10.194.21.69 with HTTP; Wed, 9 Jul 2014 18:52:49 -0700 (PDT)
In-Reply-To: <CALCETrW7JUbJTJAY3UWf6EpXWc5ij+xy3fzWXE8+-xtpsLG7CQ@mail.gmail.com>
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>
Date: Wed, 09 Jul 2014 18:52:49 -0700
Message-ID: <CACsn0c=9PuGD8p0hM6LUJKFMN_eP=UtGQN38y6DW9rsQsy1PLQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/CPesgoZduoOApFNbynQfV7vDJd4
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, Paul Hoffman <paul.hoffman@vpnc.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: Thu, 10 Jul 2014 01:52:53 -0000

On Wed, Jul 9, 2014 at 10:50 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Wed, Jul 9, 2014 at 8:33 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Wed, Jul 9, 2014 at 8:28 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>>>
>>>> 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.
>>
>> Quoting from RFC 5869, section 3.4:
>>
>>    Independence is also an important aspect of the salt value provided
>>    to a KDF.  While there is no need to keep the salt secret, and the
>>    same salt value can be used with multiple IKM values, it is assumed
>>    that salt values are independent of the input keying material.  In
>>    particular, an application needs to make sure that salt values are
>>    not chosen or manipulated by an attacker.  As an example, consider
>>    the case (as in IKE) where the salt is derived from nonces supplied
>>    by the parties in a key exchange protocol.  Before the protocol can
>>    use such salt to derive keys, it needs to make sure that these nonces
>>    are authenticated as coming from the legitimate parties rather than
>>    selected by the attacker (in IKE, for example this authentication is
>>    an integral part of the authenticated Diffie-Hellman exchange).
>>
>
> I should note that this text in 3.4 smells funny to me even taken
> alone.  Making sure that the nonces come from legitimate parties does
> *not* imply that they are independent of the IKM in any sense of the
> word "independent" that I understand.
>
> I, and presumably protocol designers everywhere, would much prefer
> language that tells me "this primitive provides this security
> guarantee if this condition is met" where the condition is clearly
> specified.
>
> This is not to say that HKDF is not a perfectly good KDF, but I find
> the RFC 5869 language unconvincing.

The reason the salt argument exists is because of a technicality in
the existence of entropy extractors:
they don't exist. Therefore, you need to make a randomized definition,
which requires a random string
independent of the other arguments.

The "obvious" way to get a salt is to do a coinflip protocol, then use
that as the salt. (That is, commit, commit, reveal,
reveal, and xor the revealed strings). This produces a random string,
independent (well, no... the attacker could abandon
the protocol round rather than continue it if they don't like it) of
other values. (To fix this you condition on successful protocol
runs, and do some math)

In the ROM none of this matters, but interestingly the eprint paper
gives a natural protocol secure in the ROM, but insecure
because a natural choice of hash function admits a length extension attack.

Without the salt argument the result is simply H(stuff), which is
supposed to be fine for any reasonable choice of H.

Sincerely,
Watson Ladd