Re: [TLS] Wrapping up cached info

Nicolas Williams <Nicolas.Williams@oracle.com> Mon, 17 May 2010 17:10 UTC

Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4DC63A6A93 for <tls@core3.amsl.com>; Mon, 17 May 2010 10:10:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.105
X-Spam-Level:
X-Spam-Status: No, score=-4.105 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeWP-sgZswCP for <tls@core3.amsl.com>; Mon, 17 May 2010 10:10:45 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 5635D3A6A27 for <tls@ietf.org>; Mon, 17 May 2010 10:10:38 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4HHAKLd007794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 May 2010 17:10:21 GMT
Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4HGxN1K009814; Mon, 17 May 2010 17:10:13 GMT
Received: from abhmt005.oracle.com by acsmt355.oracle.com with ESMTP id 247487231274116097; Mon, 17 May 2010 10:08:17 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 May 2010 10:08:16 -0700
Date: Mon, 17 May 2010 12:08:10 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Marsh Ray <marsh@extendedsubset.com>
Message-ID: <20100517170810.GY9429@oracle.com>
References: <C816DA05.66DF%uri@ll.mit.edu> <4BF168A3.40409@extendedsubset.com> <AC1CFD94F59A264488DC2BEC3E890DE50A67C326@xmb-sjc-225.amer.cisco.com> <4BF176BF.8020000@extendedsubset.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4BF176BF.8020000@extendedsubset.com>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: rcsinet15.oracle.com [148.87.113.117]
X-CT-RefId: str=0001.0A090207.4BF17882.0068:SCFMA4539811,ss=1,fgs=0
Cc: tls@ietf.org
Subject: Re: [TLS] Wrapping up cached info
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 May 2010 17:10:46 -0000

On Mon, May 17, 2010 at 12:02:55PM -0500, Marsh Ray wrote:
> On 5/17/2010 11:29 AM, Joseph Salowey (jsalowey) wrote:
> > I agree with Uri, that if you determine you need SHA-256 then you should
> > plan for hash agility.  TLS 1.2 plans for hash agility.  
> > 
> > What about Nico's proposal where a checksum is used to identify the
> > cached data and the actual handshake contains the actual data hashed
> > with the algorithm used in the PRF negotiated with the cipher suite? 
> > 
> > This way we don't have to introduce hash agility into the extension, but
> > we have cryptographic hash agility where it matters in the Finished
> > computation.  Does it solve the problem?  
> 
> It could perhaps be made to solve the problem, but IMHO it would require
> so much additional complexity (aka attack surface) that it wouldn't be
> worth it.

Really?  It'd be a single extra message consisting of the hash of all
the objects' data, concatenated in some canonical order (or maybe the
hash of the XOR of the object data hashes, to avoid having to define a
canonical order), that the first node to sent a Finished message would
have to send, and which the other node would have to check.  Where's all
that additional complexity, and how does it compare with the complexity
of the protocol's security analysis as it stands now?

> While I don't like to reject anything out-of-hand, injecting data into

But you just did.

> the calculation of the Finished messages raises a lot of concerns. The

You mis-read.  Re-read.