Re: [Cfrg] TLS PRF security proof?

Andy Lutomirski <luto@amacapital.net> Thu, 10 July 2014 03:16 UTC

Return-Path: <luto@amacapital.net>
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 F248A1A028E for <cfrg@ietfa.amsl.com>; Wed, 9 Jul 2014 20:16:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 7kTkLC_frNIo for <cfrg@ietfa.amsl.com>; Wed, 9 Jul 2014 20:16:41 -0700 (PDT)
Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45BAC1A028A for <cfrg@irtf.org>; Wed, 9 Jul 2014 20:16:41 -0700 (PDT)
Received: by mail-lb0-f170.google.com with SMTP id 10so5663217lbg.1 for <cfrg@irtf.org>; Wed, 09 Jul 2014 20:16:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=b72S7AzWhSOAuYsBJ04wonTTRA0CuYWie31Q/BS9F5k=; b=Az5HGxXl15AcXjQ/IkTGMMDsPq5inb13cHEweCX8DMFfcAI6Q74eQ2RFCMFGkw3GOE togMEa7tfS5SlHmsB0ks6SL0ivOCTIN1hTNsBDsyh+8LqbjUp6Yz8+ASUIsXA1+Q7Ikj evyo/EO9V2F7ow8hnw59V77l9Li4TpGYdEJbXxUilhXYufQ+XHq2miThEzxGzkTwHC/y lme6l/zKj3T8cfqY88gyRg4oz4gexWCrCcX4oNvtGZNc8fwRsCWGv0IMSDoTeQxMTJk6 6zE6cDxaextUBjqScuPl3DUv2Q/zxy+4f5IqKfY2kgDFAWJ89U7veGtWe+i9on29jCAH VPKQ==
X-Gm-Message-State: ALoCoQlbAakoWm497Pqfb6bODE+1VksSoEjbol1TiQmnugs8ipow8zv6nCmDtef0k9FGP9uiwXxb
X-Received: by 10.112.156.161 with SMTP id wf1mr12636169lbb.1.1404962199526; Wed, 09 Jul 2014 20:16:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.108.130 with HTTP; Wed, 9 Jul 2014 20:16:19 -0700 (PDT)
In-Reply-To: <CACsn0cmL6DcbynZkDOZST7-Voq+n217awx737dv7oy5VYWFDyg@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> <CACsn0c=9PuGD8p0hM6LUJKFMN_eP=UtGQN38y6DW9rsQsy1PLQ@mail.gmail.com> <CALCETrWo+gvVkL8P4Lw-ZtuTfu=L_q5+h9zcdpPyZvB5-FE0vg@mail.gmail.com> <CACsn0cmL6DcbynZkDOZST7-Voq+n217awx737dv7oy5VYWFDyg@mail.gmail.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Wed, 09 Jul 2014 20:16:19 -0700
Message-ID: <CALCETrX5gJdQZATrzOrXtw_M4hc320yUi_HJPuexJORUuUw07g@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Yzatka5HegpDM3mGZYA1zy3wzcY
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 03:16:43 -0000

On Wed, Jul 9, 2014 at 8:05 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
> On Wed, Jul 9, 2014 at 7:50 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Wed, Jul 9, 2014 at 6:52 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
>>
>>>
>>> Without the salt argument the result is simply H(stuff), which is
>>> supposed to be fine for any reasonable choice of H.
>>
>> If stuff is (party A data | party B data) and party A gets to choose
>> all of its data offline, then this isn't so appealing for common
>> choices of H.
>
> Why not? Is there a weakness of SHA256 I'm unaware of? If you need
> signatures, you need collision resistant hash functions.
> All uses of SHA1 and MD5 need to be ended ASAP: Microsoft has already
> begun this process.

Suppose that party A is malicious and they can find "party A data 1"
and "party A data 2" that collide.  I can imagine protocols in which
this violates one of the assumptions of the protocol.

If you allow party A to spend an extremely long time precomputing
something *before starting the protocol*, I'd like the protocol to
remain reasonably secure.  Hashes with unnecessarily small internal
state violate this.

Admittedly, it's supposed to be impractical to find even a single
collision for SHA-256, etc, but it seems unfortunate to have this type
of weakness in new protocols, hence my request for a better PRF.

FWIW, H(padded_length(stuff) | stuff | stuff) would fix this, I think.
Maybe this is a pointless consideration.

--Andy