Re: [TLS] Closing some open comments on draft-ietf-tls-renegotiation

Dr Stephen Henson <lists@drh-consultancy.demon.co.uk> Tue, 08 December 2009 12:48 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 2BB6A3A685B for <tls@core3.amsl.com>; Tue, 8 Dec 2009 04:48:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level:
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 QNHesEa1QEec for <tls@core3.amsl.com>; Tue, 8 Dec 2009 04:48:07 -0800 (PST)
Received: from claranet-outbound-smtp00.uk.clara.net (claranet-outbound-smtp00.uk.clara.net [195.8.89.33]) by core3.amsl.com (Postfix) with ESMTP id 521843A69EE for <tls@ietf.org>; Tue, 8 Dec 2009 04:48:07 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:50108 helo=[192.168.7.8]) by relay00.mail.eu.clara.net (relay.clara.net [213.253.3.40]:10587) with esmtpa (authdaemon_plain:drh) id 1NHzTt-0003p5-10 (return-path <lists@drh-consultancy.demon.co.uk>); Tue, 08 Dec 2009 12:47:53 +0000
Message-ID: <4B1E4AFA.7060600@drh-consultancy.demon.co.uk>
Date: Tue, 08 Dec 2009 12:47:54 +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: Eric Rescorla <ekr@networkresonance.com>
References: <20091207220244.DA1A06C5242@kilo.networkresonance.com>
In-Reply-To: <20091207220244.DA1A06C5242@kilo.networkresonance.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] Closing some open comments on draft-ietf-tls-renegotiation
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: Tue, 08 Dec 2009 12:48:09 -0000

Eric Rescorla wrote:
> 
> I'll also make whatever small editorial changes I see. 
> If I've missed something important that people think there is
> consensus on, please let me know. There are a lot of messages, 
> so I may well have.
> 

In 6.1:

   If clients wish to ensure that such attacks are impossible, they MUST
   terminate the connection immediately upon failure to receive the
   extension without completing the handshake.

Should we be more specific about what "terminate the connection" means? Does
that mean drop the connection immediately without sending anything else or by
sending a fatal alert? If a fatal alert which one? Presumably handshake_failure?

I'm thinking here in terms of sending something useful which would most likely
appear in server logs to help diagnose the cause: i.e. unpatched server which
strict clients refuse to connect to.

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.