Re: [TLS] Avoiding first use of RI in ClientHello

<Pasi.Eronen@nokia.com> Thu, 26 November 2009 07:18 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 C70F83A68DB for <tls@core3.amsl.com>; Wed, 25 Nov 2009 23:18:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.491
X-Spam-Level:
X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 mXaX+bQE+TU2 for <tls@core3.amsl.com>; Wed, 25 Nov 2009 23:18:57 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 8AB413A68A9 for <tls@ietf.org>; Wed, 25 Nov 2009 23:18:56 -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 nAQ7Ie3s005817; Thu, 26 Nov 2009 09:18:48 +0200
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Nov 2009 09:18:46 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Nov 2009 09:18:41 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Thu, 26 Nov 2009 08:18:40 +0100
From: Pasi.Eronen@nokia.com
To: rrelyea@redhat.com, tls@ietf.org
Date: Thu, 26 Nov 2009 08:18:38 +0100
Thread-Topic: [TLS] Avoiding first use of RI in ClientHello
Thread-Index: AcpuJwPMd7cYlBH8Rp+Xbl7wy8C92gAP6oPQ
Message-ID: <808FD6E27AD4884E94820BC333B2DB774F3113E22D@NOK-EUMSG-01.mgdnok.nokia.com>
References: <20091125223502.4265B6C3285@kilo.networkresonance.com> <4B0DBD9C.1090703@REDHAT.COM>
In-Reply-To: <4B0DBD9C.1090703@REDHAT.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: 26 Nov 2009 07:18:41.0200 (UTC) FILETIME=[AE376300:01CA6E68]
X-Nokia-AV: Clean
Subject: Re: [TLS] Avoiding first use of RI in ClientHello
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, 26 Nov 2009 07:18:58 -0000

Robert Relyea wrote:

> This is not an RI specific issue. TLS already defines a number of
> extensions. This fallback policy was implemented not because
> extension noncompliant servers were particularly important, but
> because implementations needed to have minimal objections for moving
> forward and actually using extensions. Today TLS clients regularly
> use extensions, so adding one more to allow renegotiation should not
> be an issue.

It probably isn't for clients that *already* use extensions.  The
major PC/Mac/Linux web browsers do, but those are not the only TLS
clients out there.

I can see that it could be a big issue for clients that today do not
send extensions. Not because extensions themselves are difficult to
implement, but as Eric pointed out, the fallback logic could be very
difficult to implement (and may require changing applications), and
most importantly, if you don't send extensions currently, you don't 
really know whether you need the fallback logic before you've broken 
things that work today...

Best regards,
Pasi
(not wearing any hats)