Re: [TLS] Summarizing identity change discussion so far

<Pasi.Eronen@nokia.com> Tue, 08 December 2009 19:52 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 626113A68A2 for <tls@core3.amsl.com>; Tue, 8 Dec 2009 11:52:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.545
X-Spam-Level:
X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 kRF7fOavMNIZ for <tls@core3.amsl.com>; Tue, 8 Dec 2009 11:52:29 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id DA54B3A676A for <tls@ietf.org>; Tue, 8 Dec 2009 11:52:28 -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 nB8JjpII018087; Tue, 8 Dec 2009 21:45:53 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 21:45:51 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 21:45:51 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 8 Dec 2009 20:45:50 +0100
From: Pasi.Eronen@nokia.com
To: marsh@extendedsubset.com
Date: Tue, 08 Dec 2009 20:45:49 +0100
Thread-Topic: [TLS] Summarizing identity change discussion so far
Thread-Index: Acp4H8nHqDegJlrBRyOiurK/Ct5rzgAGqeuw
Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31D2391E@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com> <4B1E4E10.90201@cs.tcd.ie> <808FD6E27AD4884E94820BC333B2DB774F31D235DE@NOK-EUMSG-01.mgdnok.nokia.com> <4B1E786A.7070100@extendedsubset.com>
In-Reply-To: <4B1E786A.7070100@extendedsubset.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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginalArrivalTime: 08 Dec 2009 19:45:51.0519 (UTC) FILETIME=[0C2032F0:01CA783F]
X-Nokia-AV: Clean
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 19:52:30 -0000

Marsh Ray wrote:

> Pasi.Eronen@nokia.com wrote:
> > The security considerations section of this draft has to describe the
> > fact that even with this fix, renegotiation does things that will
> > surprise application developers,
> 
> Does it? This fix ensures that the same party is on each end for the
> entire connection.
> 
> This rules out a MitM switching connections around. So the only
> remaining issues must involve a client or server being able to switch
> between certificates that he actually does have the private key for.
> Clients are already expected to validate the server cert for any
> protection.
> 
> My impression is that the most surprising thing about renegotiation for
> most app developers is that it can happen at all, and that their TLS
> library may be silently handling it by default. If we make any
> recommendations for TLS libraries it should be to not do renegotiation
> unless the application asks for it by registering a callback.

I think the fact that "getPeerCertificate()" and similar API calls
can return a different value each time they're called would be a
surprise to most app developers.

> > and can cause security vulnerabilities for some of them.
> 
> Do we know of any examples? I can only think of some very subtle and
> hypothetical ones that require client and server apps that are already
> coded for switching identities intentionally.

Well, although the example in James Manger's email is not real (in the
sense that it's not from real code), I think it's plausible, and it
doesn't involve an app already coded for switching identities
intentionally.

I guess an even worse example would be something like this:

  conn = openTlsConnection(host, port)
  if not verifyCertChain(conn.getPeerCert()):
     raise "Not a valid cert"
  if conn.getPeerCert().getName() != expected_name:
     raise "Name in certificate doesn't match"
  # continue...

Most TLS libraries seem to support both callback and get() style
functions for accessing/checking certificates.

Although using the callback-style APIs might be more common (and in
some sence nicer, since it allows you to abort the handshake 
a bit earlier -- but an app developer might not care about this very 
much), I think it would be a surprise to most app developers that 
using the get-style APIs might not be secure.

(And I wouldn't be surprised at all if real applications using
those get() style APIs are found...) 

Best regards,
Pasi