Re: [TLS] Summarizing identity change discussion so far

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 08 December 2009 13:01 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 13CD43A69F6 for <tls@core3.amsl.com>; Tue, 8 Dec 2009 05:01:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.442
X-Spam-Level:
X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 mTcISFSYAfFx for <tls@core3.amsl.com>; Tue, 8 Dec 2009 05:01:11 -0800 (PST)
Received: from TX2EHSOBE004.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by core3.amsl.com (Postfix) with ESMTP id 25FC53A6992 for <tls@ietf.org>; Tue, 8 Dec 2009 05:01:11 -0800 (PST)
Received: from mail156-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 8.1.340.0; Tue, 8 Dec 2009 13:01:00 +0000
Received: from mail156-tx2 (localhost.localdomain [127.0.0.1]) by mail156-tx2-R.bigfish.com (Postfix) with ESMTP id 5EC757A8483; Tue, 8 Dec 2009 13:01:00 +0000 (UTC)
X-SpamScore: -41
X-BigFish: VPS-41(zz1418M1432R98dNzz1202hzz1033ILz2dh6bh87h61h)
X-Spam-TCS-SCL: 0:0
X-FB-DOMAIN-IP-MATCH: fail
Received: from mail156-tx2 (localhost.localdomain [127.0.0.1]) by mail156-tx2 (MessageSwitch) id 1260277259826241_19176; Tue, 8 Dec 2009 13:00:59 +0000 (UTC)
Received: from TX2EHSMHS013.bigfish.com (unknown [10.9.14.252]) by mail156-tx2.bigfish.com (Postfix) with ESMTP id BC7421508057; Tue, 8 Dec 2009 13:00:59 +0000 (UTC)
Received: from imx2.tcd.ie (134.226.1.156) by TX2EHSMHS013.bigfish.com (10.9.99.113) with Microsoft SMTP Server id 14.0.482.32; Tue, 8 Dec 2009 13:00:57 +0000
Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 7675D68002; Tue, 8 Dec 2009 13:00:57 +0000 (GMT)
Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A004D472A6B; Tue, 08 Dec 2009 13:00:57 +0000
Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id 501C068002; Tue, 8 Dec 2009 13:00:57 +0000 (GMT)
Message-ID: <4B1E4E10.90201@cs.tcd.ie>
Date: Tue, 08 Dec 2009 13:01:04 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Thunderbird 2.0.0.23 (X11/20090812)
MIME-Version: 1.0
To: Pasi.Eronen@nokia.com
References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com>
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-AntiVirus-Status: MessageID = A104D472A6B
X-AntiVirus-Status: Host: imx2.tcd.ie
X-AntiVirus-Status: Action Taken:
X-AntiVirus-Status: NONE
X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.115.3)
X-Reverse-DNS: imx2.tcd.ie
Cc: tls@ietf.org
Subject: Re: [TLS] Summarizing identity change discussion so far
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: Tue, 08 Dec 2009 13:01:12 -0000

Hi Pasi,

I think that all sounds ok, except I don't see any mention
in your summary of the fact that a bunch of people (incl. me)
said that this just shouldn't be part of the re-negotiation
fix. Maybe some of those have changed their minds as a result
of the discussion though, I've not checked.

If the consensus ends up being to include some text about
this, then your approach below sounds ok to me, (though
I'd be a bit worried it might take a while to get the
right text), but I'd still rather leave it out entirely
and have some other document address the identity-change
issue in a more considered manner.

S.

Pasi.Eronen@nokia.com wrote:
> (wearing Area Director hat)
> 
> Although the IETF Last Call is still underway, here's a short attempt
> to summarize the discussion regarding identity changes (Section 7) so
> far:
> 
> - We seem to agree that changing the certificate/identity 
> during secure renegotiation (so there's no man-in-the-middle, just two
> parties) could confuse some applications.  James Manger's email provides 
> IMHO a good example of what that confusion could be (in this particular 
> example, the confusion has security implications, too):
> 
> http://www.ietf.org/mail-archive/web/tls/current/msg05122.html
> 
> - We mostly seem to agree that some applications could not just handle
> certificate/identity changes correctly, but would actually benefit
> from them. 
> 
> - We seem to agree that it would be a reasonable idea for the TLS
> library to offer the applications an option where the TLS library
> checks that the certificate doesn't change during renegotiation. 
> This is an *option* -- an application could decide not to use it, 
> and e.g. do more complex comparisons.
> 
> - We have much less support for requiring that every TLS library 
> MUST implement this functionality and/or MUST enable it by default
> (whatever "by default" means in your API), at least in this draft.
> 
> Unless I'm badly misreading the situation, or it significantly changes
> during the rest of the IETF Last Call, my proposal here would be as
> follows:
> 
> - We do NOT require (with "MUST") any changes to TLS libraries in this
> regard.
> 
> - We describe the situation a bit more clearly than the current text
> does (it seems many people found the current text somewhat unclear).
> 
> - We recommend that TLS libraries SHOULD provide identity matching
> (with memcmp, abort handshake if changed) functionality to
> applications, and SHOULD allow applications to enable/disable this
> functionality.
> 
> - We include a sentence or two describing the pros and cons of
> enabling/not enabling this feature by default, but don't require or
> recommend any particular default value.
> 
> - The text probably needs to note that if the applications wants to
> deal with identity changes, it may need to consider the "which
> application_data byte(s) correspond to which identity" question (or it
> may not -- the answer may depend a lot on the application protocol).
> 
> Does this sound like a reasonable approach?
> 
> Best regards,
> Pasi
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>