Re: [TLS] Summarizing identity change discussion so far

<Pasi.Eronen@nokia.com> Mon, 14 December 2009 08:25 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 582F63A6958 for <tls@core3.amsl.com>; Mon, 14 Dec 2009 00:25:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.549
X-Spam-Level:
X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 ON8f+OZDGpJg for <tls@core3.amsl.com>; Mon, 14 Dec 2009 00:25:31 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 43F1E3A680C for <tls@ietf.org>; Mon, 14 Dec 2009 00:25:31 -0800 (PST)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nBE8P3RK017070 for <tls@ietf.org>; Mon, 14 Dec 2009 10:25:15 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 10:25:13 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 10:25:13 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 14 Dec 2009 09:25:12 +0100
From: Pasi.Eronen@nokia.com
To: tls@ietf.org
Date: Mon, 14 Dec 2009 09:25:11 +0100
Thread-Topic: [TLS] Summarizing identity change discussion so far
Thread-Index: Acp5I0jkyt8EuQ9iT5KPjsufPrpIgwDc3XyA
Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31E7F189@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> <808FD6E27AD4884E94820BC333B2DB774F31D2391E@NOK-EUMSG-01.mgdnok.nokia.com> <4B202BCD.40500@extendedsubset.com>
In-Reply-To: <4B202BCD.40500@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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 14 Dec 2009 08:25:13.0977 (UTC) FILETIME=[F5884E90:01CA7C96]
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: Mon, 14 Dec 2009 08:25:32 -0000

Marsh Ray wrote:

> > 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...
> 
> _After_ renegotation is fixed (and/or disabled by default) though, how
> is this a problem? RI proves the data has come from the same remote
> endpoint. That same remote endpoint has proven that he can supply an
> acceptable cert, too.

Ah -- I now see that my example was not very clear. The intent was
that renegotiation happens after the first "if" statement but before
the second one. So the certificate that gets used (in the 2nd "if") 
isn't actually the one that was validated (by the 1st "if").
That would obviously be a huge security vulnerability...

Best regards,
Pasi
(not wearing any hats)