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

Bodo Moeller <bmoeller@acm.org> Mon, 16 November 2009 03:29 UTC

Return-Path: <bmoeller@acm.org>
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 C28563A6A5A for <tls@core3.amsl.com>; Sun, 15 Nov 2009 19:29:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.961
X-Spam-Level:
X-Spam-Status: No, score=-101.961 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100]
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 zgwCslJdAlRX for <tls@core3.amsl.com>; Sun, 15 Nov 2009 19:29:40 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by core3.amsl.com (Postfix) with ESMTP id BE0FC3A68EA for <tls@ietf.org>; Sun, 15 Nov 2009 19:29:39 -0800 (PST)
Received: from [10.1.65.88] (216-239-44-65.google.com [216.239.44.65]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0LhAEV-1Ny6TS3dDD-00oAgD; Mon, 16 Nov 2009 04:29:36 +0100
From: Bodo Moeller <bmoeller@acm.org>
To: mrex@sap.com
In-Reply-To: <200911160010.nAG0AP0f001956@fs4113.wdf.sap.corp>
References: <200911160010.nAG0AP0f001956@fs4113.wdf.sap.corp>
Message-Id: <64B5DE9F-10F4-4D7E-9762-6E16E130D43B@acm.org>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sun, 15 Nov 2009 19:29:31 -0800
X-Mailer: Apple Mail (2.936)
X-Provags-ID: V01U2FsdGVkX18REPn8Z5jaJkWWNL6Le13c6GRzMaVwwCnyojZ QeeIhvOC2weQTm0lWbh4YxFQAkwGR37UK5+JZzLX2W66yqGw0t uv3cnDYcG3i3+duDPLgNQ==
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
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 03:29:40 -0000

On Nov 15, 2009, at 4:10 PM, Martin Rex wrote:
> 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.

Thanks, I can see your point.

My assumption was that we wouldn't mind breaking legacy renegotiation  
handshakes (we'd expect all servers that allow renegotiation to be  
updated such that they *never* allow legacy renegotiation), and that  
we'd just want *initial* handshakes to continue to work between  
updated clients and current servers.  That's just enough backwards  
compatibility such that client-side users can actually update their  
software without having to wait for all servers to get updated first.

I'm not convinced that we'd want updated servers to offer legacy  
renegotiation, but if we do, then using a pseudo ciphersuite seems  
fine to let the client indicate that it doesn't want legacy  
renegotiation (i.e., the present handshake is not a renegotiation  
handshake, and if the servers sees it as one, it should abort the  
connection immediately because it's with a MitM).

Bodo