Re: [TLS] Summarizing identity change discussion so far

<Pasi.Eronen@nokia.com> Thu, 17 December 2009 21:31 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 253D43A67F3 for <tls@core3.amsl.com>; Thu, 17 Dec 2009 13:31:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.554
X-Spam-Level:
X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 R2Azk5PNE+td for <tls@core3.amsl.com>; Thu, 17 Dec 2009 13:31:41 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 7D9BA3A6778 for <tls@ietf.org>; Thu, 17 Dec 2009 13:31:40 -0800 (PST)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nBHLVKZP027409 for <tls@ietf.org>; Thu, 17 Dec 2009 23:31:23 +0200
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 23:28:53 +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); Thu, 17 Dec 2009 23:28:49 +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; Thu, 17 Dec 2009 22:28:48 +0100
From: Pasi.Eronen@nokia.com
To: tls@ietf.org
Date: Thu, 17 Dec 2009 22:28:47 +0100
Thread-Topic: Summarizing identity change discussion so far
Thread-Index: Acp35q+5MB/IK2o8TM+TSRCqs64JxAHeEGWw
Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31F77BBB@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com>
In-Reply-To: <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: 17 Dec 2009 21:28:49.0030 (UTC) FILETIME=[EBED5260:01CA7F5F]
X-Nokia-AV: Clean
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: Thu, 17 Dec 2009 21:31:42 -0000

Here's proposed text for the Security Considerations section about the
identity changes. The discussion on the list seemed to favor keeping
the normative parts quite mild, so much of this is worded as advice
for people to consider (or ignore, if they so choose), not as strict 
requirements:

   While this extension mitigates the man-in-the-middle attack
   described in the overview, it does not resolve all possible
   problems an application may face if it is unaware of renegotiation.
   In particular, either the client or the server can during
   renegotiation present a different certificate than was used
   earlier, and this may become as a surprise to application
   developers (who might have expected, for example, that a
   "getPeerCertificates()" API call returns the same value if called
   twice), and might be handled in an insecure way.
   
   TLS implementers are encouraged to clearly document how
   renegotiation interacts with the APIs offered to applications (for
   example, which API calls might return different values on different
   calls, or which callbacks might get called multiple times).

   To make life simpler for applications that do not expect the peer's
   certificate to change once it's been authentication, TLS
   implementations MAY offer the applications the option abort the
   renegotiation if the peer tries to authenticate with a different
   certificate and/or different server name (in the server_name
   extension) than was used earlier. However, enabling this option by
   default for all applications could break existing applications that
   depend on using renegotiation to present multiple certificates.
   TLS implementations SHOULD also offer the applications the option
   to disable renegotiation completely.

   Finally, designers of applications that depend on renegotiation are
   reminded that many TLS APIs represent application data as a simple
   octet stream; applications may not be able to determine exactly
   which application data octets were received before, during, or
   after renegotiation. Especially if the peer presents a different 
   certificate during renegotiation, care is needed when specifying
   how the application should handle the data.

Comments (and especially concrete proposals for improving the text)
are welcome.

Best regards,
Pasi

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
> Eronen Pasi (Nokia-NRC/Helsinki)
> Sent: 08 December, 2009 11:13
> To: tls@ietf.org
> Subject: [TLS] Summarizing identity change discussion so far
> 
> (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