Re: [TLS] assert TLSext in renego-ServerHello instead of disable

Martin Rex <mrex@sap.com> Mon, 16 November 2009 00:10 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 5F15A3A6832 for <tls@core3.amsl.com>; Sun, 15 Nov 2009 16:10:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.628
X-Spam-Level:
X-Spam-Status: No, score=-5.628 tagged_above=-999 required=5 tests=[AWL=0.621, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 nHg7HdYhJ1sW for <tls@core3.amsl.com>; Sun, 15 Nov 2009 16:10:30 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 282033A6A42 for <tls@ietf.org>; Sun, 15 Nov 2009 16:10:29 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAG0APsQ026067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2009 01:10:25 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911160010.nAG0AP0f001956@fs4113.wdf.sap.corp>
To: ekr@networkresonance.com
Date: Mon, 16 Nov 2009 01:10:25 +0100
In-Reply-To: <20091115233509.C2E8A69F83F@kilo.networkresonance.com> from "Eric Rescorla" at Nov 16, 9 01:35:09 am
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] assert TLSext in renego-ServerHello instead of disable
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: Mon, 16 Nov 2009 00:10:31 -0000

Eric Rescorla wrote:
> 
> Bodo Moeller wrote:
> > 
> > Why make a client send it on the initial handshake if that client  
> > wouldn't have plans to abort the connection if the server doesn't  
> > acknowledge it?  Interoperability seems easier if you don't send it.
> 
> Agreed. I've rethought this point since I wrote it.

I see value in extension-less signaling on initial handshake,
because it will immediately provide protection to updated clients
when the server is updated even when both, client and server still
support the insecure renegotiation (i.e. very early in the
transition period) or the client still allowys a reconnect
fallback with an extension-less ClientHello.

-Martin