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

Eric Rescorla <ekr@networkresonance.com> Mon, 09 November 2009 22:14 UTC

Return-Path: <ekr@networkresonance.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 5237628C275 for <tls@core3.amsl.com>; Mon, 9 Nov 2009 14:14:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.029
X-Spam-Level:
X-Spam-Status: No, score=0.029 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
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 5avUeFcmWr+s for <tls@core3.amsl.com>; Mon, 9 Nov 2009 14:14:06 -0800 (PST)
Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id D05C828C279 for <tls@ietf.org>; Mon, 9 Nov 2009 14:14:04 -0800 (PST)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 9F24569E672; Mon, 9 Nov 2009 14:15:12 -0800 (PST)
Date: Mon, 09 Nov 2009 14:15:11 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: mrex@sap.com
In-Reply-To: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp>
References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20091109221512.9F24569E672@kilo.networkresonance.com>
Cc: tls@ietf.org
Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego
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: Mon, 09 Nov 2009 22:14:08 -0000

At Mon, 9 Nov 2009 21:35:57 +0100 (MET),
Martin Rex wrote:
> 
> Maybe a patched Server (one with support for secure renegotiation)
> should ALWAYS assert this extension in a renegotiation TLS handshake
> _with_ the verify_data of both server.finished and client.finished
> in the ServerHello -- including when the client didn't send the
> extension (maybe because the client didn't dare confusing an SSLv3 server).

This is forbidden by RFC 4366: servers can only send what the client
offers:

   Note that for all extension types (including those defined in the
   future), the extension type MUST NOT appear in the extended server
   hello unless the same extension type appeared in the corresponding
   client hello.  Thus clients MUST abort the handshake if they receive
   an extension type in the extended server hello that they did not
   request in the associated (extended) client hello.

-Ekr