[TLS] Summarizing identity change discussion so far

<Pasi.Eronen@nokia.com> Tue, 08 December 2009 09:14 UTC

Return-Path: <Pasi.Eronen@nokia.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 824D93A6995 for <tls@core3.amsl.com>; Tue, 8 Dec 2009 01:14:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.528
X-Spam-Level:
X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 046JKfwri5DY for <tls@core3.amsl.com>; Tue, 8 Dec 2009 01:14:15 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D4CC33A67AA for <tls@ietf.org>; Tue, 8 Dec 2009 01:14:14 -0800 (PST)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nB89DiTp011107 for <tls@ietf.org>; Tue, 8 Dec 2009 11:14:01 +0200
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 11:13:34 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 11:13:29 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 8 Dec 2009 10:13:22 +0100
From: Pasi.Eronen@nokia.com
To: tls@ietf.org
Date: Tue, 08 Dec 2009 10:13:20 +0100
Thread-Topic: Summarizing identity change discussion so far
Thread-Index: Acp35q+5MB/IK2o8TM+TSRCqs64JxA==
Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 08 Dec 2009 09:13:29.0852 (UTC) FILETIME=[B52143C0:01CA77E6]
X-Nokia-AV: Clean
Subject: [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 09:14:16 -0000

(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