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

Martin Rex <mrex@sap.com> Tue, 08 December 2009 17:24 UTC

Return-Path: <mrex@sap.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 D0CE03A6A1B for <tls@core3.amsl.com>; Tue, 8 Dec 2009 09:24:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.893
X-Spam-Level:
X-Spam-Status: No, score=-5.893 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_24=0.6, 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 rWxGLYoRylHI for <tls@core3.amsl.com>; Tue, 8 Dec 2009 09:24:25 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id D96683A6A26 for <tls@ietf.org>; Tue, 8 Dec 2009 09:24:24 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nB8HOA9k000984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Dec 2009 18:24:10 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912081724.nB8HO9RE023884@fs4113.wdf.sap.corp>
To: lists@drh-consultancy.demon.co.uk
Date: Tue, 08 Dec 2009 18:24:09 +0100
In-Reply-To: <4B1E8679.4000200@drh-consultancy.demon.co.uk> from "Dr Stephen Henson" at Dec 8, 9 05:01:45 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
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
Reply-To: mrex@sap.com
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 17:24:25 -0000

Dr Stephen Henson wrote:
> 
> Just to be clear here: I'm not referring to an attack but where we have
> a strict patched client that refuses to connect to an unpatched server.
> That is client makes initial handshake using RI+MCSV, doesn't get RI
> back and decides this is not acceptable.
> 
> This is a scenario which is quite likely to happen at some point. Well it
> happens already in my test environment ;-)
> 
> I'm asking whether a client should send a fatal alert here so a server
> admin can get some hint of the cause or if it should just silently
> drop the connection.

If this were a _new_ spec, then I would suggest a SHOULD.

But since we're going back in time, and there seem to be a number
of implementations that are notoriously bad and sending and
receiving SSL alerts, I definitely would not want to create
any false hopes.

In the situation that you're describing, it is the updated client
that determines that it doesn't want continue talking to the old server,
and so the set of available Alerts that could make any sense
to an old server is those known to SSLv3,  IMHO.

-Martin