Re: [TLS] Justification

Nicolas Williams <Nicolas.Williams@oracle.com> Wed, 12 May 2010 18:58 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 C102728C16F for <tls@core3.amsl.com>; Wed, 12 May 2010 11:58:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.226
X-Spam-Level:
X-Spam-Status: No, score=-5.226 tagged_above=-999 required=5 tests=[AWL=1.372, BAYES_00=-2.599, 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 4XFtac7F5c0c for <tls@core3.amsl.com>; Wed, 12 May 2010 11:58:21 -0700 (PDT)
Received: from rcsinet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by core3.amsl.com (Postfix) with ESMTP id 186703A68E6 for <tls@ietf.org>; Wed, 12 May 2010 11:44:21 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o4CIi3Os025402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 May 2010 18:44:05 GMT
Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4C7D8Dd026951; Wed, 12 May 2010 18:44:02 GMT
Received: from abhmt017.oracle.com by acsmt353.oracle.com with ESMTP id 259475971273689782; Wed, 12 May 2010 11:43:02 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 11:43:02 -0700
Date: Wed, 12 May 2010 13:42:57 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Michael D'Errico <mike-list@pobox.com>
Message-ID: <20100512184257.GL9429@oracle.com>
References: <4BEAC145.60607@pobox.com> <n2va84d7bc61005120811o737c2011i27f9d40e88417539@mail.gmail.com> <004901caf1ea$783e23a0$68ba6ae0$@briansmith.org> <p2xa84d7bc61005120858v2ce68cf7xe6ddf559faf4d4b0@mail.gmail.com> <4BEAE4CF.7070205@pobox.com> <p2ga84d7bc61005121033n169fc0fdyb2bc94b504f3fc2c@mail.gmail.com> <20100512180814.GI9429@oracle.com> <4BEAF1F8.4030004@pobox.com> <20100512182827.GJ9429@oracle.com> <4BEAF52B.9090801@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4BEAF52B.9090801@pobox.com>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Source-IP: acsmt353.oracle.com [141.146.40.153]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4BEAF6F3.0041:SCFMA4539814,ss=1,fgs=0
Cc: tls@ietf.org
Subject: Re: [TLS] Justification
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: Wed, 12 May 2010 18:58:22 -0000

On Wed, May 12, 2010 at 11:36:27AM -0700, Michael D'Errico wrote:
> Nicolas Williams wrote:
> >On Wed, May 12, 2010 at 11:22:48AM -0700, Michael D'Errico wrote:
> >>Would they be https URL's?  Then you would have an infinite-recursion
> >>problem....
> >
> >No, why should they be?  The data is public, and integrity protection
> >would be provided by having the objects be added as inputs to the
> >Finished message computation.
> 
> Whoa, changing the Finished computation?  I understand that that
> would work, but we weren't even willing to do that to solve the
> exploitable MITM-thru-renegotiation problem.

Paul Hoffman proposes an extension to add inputs to the Finished message
computation.  There's no objection yet to Paul's proposal on the grounds
you state.

In any case, one of the problems with the caching extension as proposed
result from not binding the cached objects to the Finished message,
which at the very least complicates the security analysis of the
protocol, and possibly compromises it altogether.  We MUST NOT make the
same mistakes we've made before.

Nico
--