Re: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt

<Pasi.Eronen@nokia.com> Wed, 11 November 2009 09:26 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 16C163A6A10 for <tls@core3.amsl.com>; Wed, 11 Nov 2009 01:26:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.541
X-Spam-Level:
X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 UbtKojcUvva7 for <tls@core3.amsl.com>; Wed, 11 Nov 2009 01:26:16 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id D9BBE3A69DC for <tls@ietf.org>; Wed, 11 Nov 2009 01:26:15 -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 nAB9QBV3002220; Wed, 11 Nov 2009 11:26:38 +0200
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 11:26:31 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 11:26:26 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 11 Nov 2009 10:26:26 +0100
From: Pasi.Eronen@nokia.com
To: ekr@networkresonance.com, lists@drh-consultancy.demon.co.uk
Date: Wed, 11 Nov 2009 10:26:24 +0100
Thread-Topic: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt
Thread-Index: AcphZl0IRV0SUUsnQJa6bArduTagPQBSSGSg
Message-ID: <808FD6E27AD4884E94820BC333B2DB774F30DD16F6@NOK-EUMSG-01.mgdnok.nokia.com>
References: <1b587cab0911080935m64eabca8t6f7f6dfb9a666d06@mail.gmail.com> <p06240806c71ce60888e1@[133.93.128.35]> <4AF73817.4080802@extendedsubset.com> <20091108231234.4A72569E39E@kilo.networkresonance.com> <4AF83FB9.9060302@drh-consultancy.demon.co.uk> <20091109175954.8DF8F69E5CB@kilo.networkresonance.com>
In-Reply-To: <20091109175954.8DF8F69E5CB@kilo.networkresonance.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: 11 Nov 2009 09:26:26.0932 (UTC) FILETIME=[0B270340:01CA62B1]
X-Nokia-AV: Clean
Cc: tls@ietf.org
Subject: Re: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt
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: Wed, 11 Nov 2009 09:26:17 -0000

Eric Rescorla wrote:

> I don't think the problem here is really the code point assignment.
> 
> I would imagine the IESG and IANA to be pretty good about doing
> advance assignments once the WG has converged on the exact contents
> of the extension. I know we had pretty good consensus within a
> smaller group, but if when we run it by some cryptographers they say
> it's insecure we'll need to change it, at which point it won't
> really help to have deployed code with the "early" code point.

<wearing area director hat>

I think this is one of those cases where an exception to the usual
procedures might be in order, but the "once the WG has converged on
the exact contents" is an important point here. It's relatively rare
that the -00 version of some internet draft and the final RFC are
actually interoperable.

Using the same extension number for multiple incompatible versions of
the draft is probably not a good idea (and probably not very secure,
either -- if the handshake fails, you don't know if it's due to an
attack or just interoperability problem, and the latter might be much
more likely), and I'd like to avoid allocating multiple extension
numbers for different versions of the draft, too.

I certainly hope the WG converges on the contents relatively fast.
The TLS WG is meeting tomorrow (Thursday), so we'll see soon.

Best regards,
Pasi