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

Dr Stephen Henson <lists@drh-consultancy.demon.co.uk> Wed, 11 November 2009 18:59 UTC

Return-Path: <lists@drh-consultancy.demon.co.uk>
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 C03D93A6957 for <tls@core3.amsl.com>; Wed, 11 Nov 2009 10:59:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 ixQ5pUfIBMKA for <tls@core3.amsl.com>; Wed, 11 Nov 2009 10:59:06 -0800 (PST)
Received: from claranet-outbound-smtp04.uk.clara.net (claranet-outbound-smtp04.uk.clara.net [195.8.89.37]) by core3.amsl.com (Postfix) with ESMTP id DC1553A6B00 for <tls@ietf.org>; Wed, 11 Nov 2009 10:59:05 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:53540 helo=[192.168.7.8]) by relay04.mail.eu.clara.net (relay.clara.net [213.253.3.44]:10587) with esmtpa (authdaemon_plain:drh) id 1N8IPh-0002yf-E6 (Exim 4.69) (return-path <lists@drh-consultancy.demon.co.uk>); Wed, 11 Nov 2009 18:59:29 +0000
Message-ID: <4AFB0995.8060504@drh-consultancy.demon.co.uk>
Date: Wed, 11 Nov 2009 18:59:33 +0000
From: Dr Stephen Henson <lists@drh-consultancy.demon.co.uk>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Pasi.Eronen@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> <808FD6E27AD4884E94820BC333B2DB774F30DD16F6@NOK-EUMSG-01.mgdnok.nokia.com>
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F30DD16F6@NOK-EUMSG-01.mgdnok.nokia.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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 18:59:07 -0000

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.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.