Re: [TLS] Justification

Marsh Ray <marsh@extendedsubset.com> Wed, 12 May 2010 19:46 UTC

Return-Path: <marsh@extendedsubset.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 81E483A67F0 for <tls@core3.amsl.com>; Wed, 12 May 2010 12:46:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.771
X-Spam-Level:
X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[AWL=0.828, BAYES_00=-2.599]
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 hQe7QZ5pmHrm for <tls@core3.amsl.com>; Wed, 12 May 2010 12:46:58 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id A46A43A6891 for <tls@ietf.org>; Wed, 12 May 2010 12:46:42 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1OCHt2-0009UB-7O for tls@ietf.org; Wed, 12 May 2010 19:46:32 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 34418631D for <tls@ietf.org>; Wed, 12 May 2010 19:46:31 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18esSUSSO0os4ekZrOIXpjFM/LyIv+IpSg=
Message-ID: <4BEB0598.9070209@extendedsubset.com>
Date: Wed, 12 May 2010 14:46:32 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: tls@ietf.org
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> <20100512184257.GL9429@oracle.com>
In-Reply-To: <20100512184257.GL9429@oracle.com>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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 19:46:59 -0000

On 5/12/2010 1:42 PM, Nicolas Williams wrote:
> On Wed, May 12, 2010 at 11:36:27AM -0700, Michael D'Errico wrote:
>>
>> 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.

I'm not sure the discussion got that far, so it's not evidence of much.

> 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.

Agreed, but we should be just as careful not to make new ones.

Sorry if you explained this earlier, but how would the "use URLs"
approach be different than an arbitrary server-chosen identifier?

- Marsh