Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt

Dr Stephen Henson <lists@drh-consultancy.demon.co.uk> Sat, 21 November 2009 18:01 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 11EA33A6A13 for <tls@core3.amsl.com>; Sat, 21 Nov 2009 10:01:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.652
X-Spam-Level:
X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=-0.053, 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 30HdM42eH98Q for <tls@core3.amsl.com>; Sat, 21 Nov 2009 10:01:40 -0800 (PST)
Received: from claranet-outbound-smtp06.uk.clara.net (claranet-outbound-smtp06.uk.clara.net [195.8.89.39]) by core3.amsl.com (Postfix) with ESMTP id 32CEE3A689E for <tls@ietf.org>; Sat, 21 Nov 2009 10:01:39 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:49191 helo=[192.168.7.8]) by relay06.mail.eu.clara.net (relay.clara.net [213.253.3.46]:10587) with esmtpa (authdaemon_plain:drh) id 1NBuH8-00045c-Lj (Exim 4.69) for tls@ietf.org (return-path <lists@drh-consultancy.demon.co.uk>); Sat, 21 Nov 2009 18:01:35 +0000
Message-ID: <4B082B08.3020406@drh-consultancy.demon.co.uk>
Date: Sat, 21 Nov 2009 18:01:44 +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: tls@ietf.org
References: <AC1CFD94F59A264488DC2BEC3E890DE5092192D6@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE5092192D6@xmb-sjc-225.amer.cisco.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.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: Sat, 21 Nov 2009 18:01:42 -0000

Joseph Salowey (jsalowey) wrote:
> We have had a lot of good discussion on this list, but I think we need
> to start converging on a solution. As I said in a previous message, I've
> asked Eric to serve as editor for the WG draft and he has posted
> draft-ietf-tls-renegotiation-00 as a starting point.  I realize that
> there are a number of people who aren't happy with aspects of the draft,
> or indeed with the draft as a whole, but I'd like to get the sense for
> the feelings of the group as a whole. If we have rough consensus that
> this is a workable approach, we can try to nail down the remaining
> issues and move forward.
> 
> To try to keep this concrete, please respond with answers to this
> question:
> 
> Support for the draft:
> - I support this draft
> - I support this draft with the following modification
> - I would support an entirely different proposal (please identify it; be
> specific) 
> 
> If you are proposing a modification, in addition to providing a
> description and rationale for a modification to the document it is
> helpful to provide sample text of the modification. Also, please
> indicate whether you would only support the draft with your modification
> or whether you can live with it unmodified.  
> 

Firstly does this mean the 00 draft or the 01 one?

I've mentioned elsewhere the fact that neither addresses SSLv2 or SSLv3
compatible client hellos (which may well end up talking TLS but they don't know
that initially) and talk of fallbacks doesn't address APIs or libraries that
cannot transparently reconnect.

I'm not really concerned how this is addressed. I would support the 01 draft
with the following modifications:

1. The magic ciphersuite as well as being used as a fallback can be used on
initial connections if the client wishes to send an SSLv2 or SSLv3 compatible
client hello or a TLS one without extensions.

2. Any server which accepts an SSLv2 or SSLv3 compatible client hello MUST be
able to recognise the magic ciphersuite.

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.