Re: [TLS] Verify data in the RI extension?

<Pasi.Eronen@nokia.com> Fri, 27 November 2009 20:11 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 D2D2C3A68AF for <tls@core3.amsl.com>; Fri, 27 Nov 2009 12:11:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.508
X-Spam-Level:
X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 eF5C3UXFb2iP for <tls@core3.amsl.com>; Fri, 27 Nov 2009 12:11:20 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 7FB413A699E for <tls@ietf.org>; Fri, 27 Nov 2009 12:11:17 -0800 (PST)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nARKB8BS008614; Fri, 27 Nov 2009 22:11:08 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 22:11:03 +0200
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 22:11:03 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 22:10:58 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Fri, 27 Nov 2009 21:10:57 +0100
From: Pasi.Eronen@nokia.com
To: mrex@sap.com
Date: Fri, 27 Nov 2009 21:10:55 +0100
Thread-Topic: [TLS] Verify data in the RI extension?
Thread-Index: AcpvjCagBvHY2IhmRA+hEL1HdO2bDAAEP47g
Message-ID: <808FD6E27AD4884E94820BC333B2DB774F3118C377@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB774F3118C344@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Nov 27, 9 06:30:43 pm <200911271804.nARI4u3v011522@fs4113.wdf.sap.corp>
In-Reply-To: <200911271804.nARI4u3v011522@fs4113.wdf.sap.corp>
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: 27 Nov 2009 20:10:58.0475 (UTC) FILETIME=[BBCC2FB0:01CA6F9D]
X-Nokia-AV: Clean
Cc: tls@ietf.org
Subject: Re: [TLS] Verify data in the RI extension?
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: Fri, 27 Nov 2009 20:11:28 -0000

Martin Rex wrote:

> > I think "what would the SSLv3 designers have done" (almost 15 years
> > ago) and "what should we today" are two completely different
> > questions, which may have completely different answers.
> 
> If we were discussing a new feature for TLSv1.2 or TLSv1.3 only, I
> would agree.
> 
> But we're actually going back to code that is 10 years or more and
> want that fixed as well.  So we need to pay a little more attention
> to the perils of poor souls from the dirty old cruft department than
> to the dreams of the nerds from the fancy new features department.

I fully agree that deployment (even with old implementations) needs to
be taken into account -- otherwise we'd be ignoring reality.

But *none* of the proposals made so far would be the solution SSLv3
designers would have picked, had someone pointed out this problem
before implementations had shipped. For starters, they would not have
needed signalling (in either direction), which is one of the main
issues we're facing today...

Best regards,
Pasi
(not wearing any hats)