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

Eric Rescorla <ekr@networkresonance.com> Thu, 12 November 2009 06:07 UTC

Return-Path: <ekr@networkresonance.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 56F5C3A69DD for <tls@core3.amsl.com>; Wed, 11 Nov 2009 22:07:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.095
X-Spam-Level:
X-Spam-Status: No, score=0.095 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1]
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 ey+hO2fgYIRC for <tls@core3.amsl.com>; Wed, 11 Nov 2009 22:07:43 -0800 (PST)
Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id 276603A69CC for <tls@ietf.org>; Wed, 11 Nov 2009 22:07:43 -0800 (PST)
Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N8Sqp-0007x8-00 for tls@ietf.org; Thu, 12 Nov 2009 08:08:11 +0200
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 09F3169EF21; Thu, 12 Nov 2009 08:09:07 +0200 (EET)
Date: Thu, 12 Nov 2009 08:09:06 +0200
From: Eric Rescorla <ekr@networkresonance.com>
To: Dr Stephen Henson <lists@drh-consultancy.demon.co.uk>
In-Reply-To: <4AFB0995.8060504@drh-consultancy.demon.co.uk>
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> <808FD6E27AD4884E94820BC333B2DB774F30DD16F6@NOK-EUMSG-01.mgdnok.nokia.com> <4AFB0995.8060504@drh-consultancy.demon.co.uk>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20091112060907.09F3169EF21@kilo.networkresonance.com>
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: Thu, 12 Nov 2009 06:07:44 -0000

At Wed, 11 Nov 2009 18:59:33 +0000,
Dr Stephen Henson wrote:
> 
> Pasi.Eronen@nokia.com wrote:
> > 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.
> > 
> 
> Would including a version number in the extension help? Then if the format does
> change implementations can indicate that it is a version they don't support or
> decide they are willing to support an older version.
> 
> This would also cover the case where some cryptographic attack is found against
> the current form later. We keep the extension number but bump up the version.

I considered that, but I'm not sure it really helps. Once the initial version
is widely supported you need to send the old version as well as the new
version for a smooth transition. Might as well have two extension code
points.

-Ekr