Re: [TLS] simplistic renego protection
Nasko Oskov <noskov@microsoft.com> Thu, 19 November 2009 20:56 UTC
Return-Path: <noskov@microsoft.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 265B33A69EC for <tls@core3.amsl.com>; Thu, 19 Nov 2009 12:56:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 9pQiBoiRbAS4 for <tls@core3.amsl.com>; Thu, 19 Nov 2009 12:56:06 -0800 (PST)
Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 33B783A6855 for <tls@ietf.org>; Thu, 19 Nov 2009 12:56:06 -0800 (PST)
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 19 Nov 2009 12:56:25 -0800
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server id 14.0.639.21; Thu, 19 Nov 2009 12:56:03 -0800
Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Thu, 19 Nov 2009 12:56:01 -0800
From: Nasko Oskov <noskov@microsoft.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] simplistic renego protection
Thread-Index: AQHKaInFGiEOTOvqREmP25vm9DLXVpE9LikAgABcDpCAAMF4AIAAA+wA//+TmtA=
Date: Thu, 19 Nov 2009 20:54:17 +0000
Deferred-Delivery: Thu, 19 Nov 2009 20:55:00 +0000
Message-ID: <B197003731D4874CA41DE7B446BBA3E829CD37CA@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com>
References: <200911182000.nAIK0Qkm013905@fs4113.wdf.sap.corp> <4B04A792.7040607@jacaranda.org> <B197003731D4874CA41DE7B446BBA3E829CD28F1@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <4B059716.6010309@jacaranda.org> <4B059A60.9000003@jacaranda.org>
In-Reply-To: <4B059A60.9000003@jacaranda.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [TLS] simplistic renego protection
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: Thu, 19 Nov 2009 20:56:07 -0000
David-Sarah Hopwood wrote: >>>> This is a non-sequitur. Lenient clients don't need to send the >>>> extension in the ClientHello of an initial handshake. Strict clients >>>> must not be able to talk to unpatched servers, by definition. >>> I must be misunderstanding the attack. Why is the attack not possible >>> even when client doesn't send the RI extension on initial handshake? >> >> Because the server knows that the connection is a renegotiation from >> its point of view, and therefore it rejects any handshake that doesn't >> contain the extension. >> >>> If the MiTM sends a client hello to the server that has no extension, >>> then the server has no way to drop the connection. This will require >>> a strict server to prevent the attack and strict server config will >>> not be reality for a long time. What am I missing? >> >> That, in the RI approach, strict server config is essential from the start. > >Point of clarification: "strict server" here means that the server does not >accept *renegotiations* with an unpatched client. It still accepts initial >handshakes. Thanks for the clarification. We seem to differ in the definition of strict server config. This clarifies it. You are assuming then that admins will have to upgrade any clients that do renegotiation before they upgrade their servers, otherwise there will be interop problem. Am I correct? This will mean that admins for sites that require client authentication will not be upgrading their servers until their entire set of clients have patched browsers. There is an option to rearchitect the site, but that might not be possible. >A "strict client", OTOH, will refuse to make even initial connections to an >unpatched server. So support for lenient (as well as strict) clients is >certainly necessary, but whether support for lenient servers is needed is >much less clear. Great! We are in consensus on the client definition of lenient and the need to support that. >> We haven't yet established whether the ability to support lenient >> servers is a requirement. Eric has argued against allowing that; so have I. >> If lenient servers are allowed, then I think it will take *much* >> longer until the vulnerability is eliminated from most connections. There seems to be 3 different ways to define the server behavior: * allow anyone * don't allow renegotiation from unpatched clients * don't allow initial negotiation from unpatched clients We should be clear on which ones we call strict and lenient. Nasko
- Re: [TLS] simplistic renego protection Chris Newman
- [TLS] simplistic renego protection Martin Rex
- Re: [TLS] simplistic renego protection Michael D'Errico
- Re: [TLS] simplistic renego protection Joseph Salowey (jsalowey)
- Re: [TLS] simplistic renego protection Martin Rex
- Re: [TLS] simplistic renego protection Martin Rex
- Re: [TLS] simplistic renego protection Eric Rescorla
- Re: [TLS] simplistic renego protection Eric Rescorla
- Re: [TLS] simplistic renego protection Martin Rex
- Re: [TLS] simplistic renego protection Martin Rex
- Re: [TLS] simplistic renego protection Eric Rescorla
- Re: [TLS] simplistic renego protection Eric Rescorla
- Re: [TLS] simplistic renego protection Marsh Ray
- Re: [TLS] simplistic renego protection Martin Rex
- Re: [TLS] simplistic renego protection Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] simplistic renego protection Michael D'Errico
- Re: [TLS] simplistic renego protection Marsh Ray
- Re: [TLS] simplistic renego protection Michael D'Errico
- Re: [TLS] simplistic renego protection Marsh Ray
- Re: [TLS] simplistic renego protection Martin Rex
- Re: [TLS] simplistic renego protection David-Sarah Hopwood
- Re: [TLS] simplistic renego protection David-Sarah Hopwood
- Re: [TLS] simplistic renego protection David-Sarah Hopwood
- Re: [TLS] simplistic renego protection Martin Rex
- Re: [TLS] simplistic renego protection Martin Rex
- Re: [TLS] simplistic renego protection Nelson B Bolyard
- Re: [TLS] simplistic renego protection Michael D'Errico
- Re: [TLS] simplistic renego protection Michael D'Errico
- Re: [TLS] simplistic renego protection peter.robinson
- Re: [TLS] simplistic renego protection Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [TLS] simplistic renego protection Stephen Farrell
- Re: [TLS] simplistic renego protection Martin Rex
- Re: [TLS] simplistic renego protection Michael D'Errico
- Re: [TLS] simplistic renego protection Eric Rescorla
- Re: [TLS] simplistic renego protection Nasko Oskov
- Re: [TLS] simplistic renego protection Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] simplistic renego protection Michael D'Errico
- Re: [TLS] simplistic renego protection Yair Elharrar
- Re: [TLS] simplistic renego protection Steve Dispensa
- Re: [TLS] simplistic renego protection Eric Rescorla
- Re: [TLS] simplistic renego protection Eric Rescorla
- Re: [TLS] simplistic renego protection Marsh Ray
- Re: [TLS] simplistic renego protection Michael D'Errico
- Re: [TLS] simplistic renego protection Eric Rescorla
- Re: [TLS] simplistic renego protection Robert Dugal
- Re: [TLS] simplistic renego protection Pasi.Eronen
- Re: [TLS] simplistic renego protection Martin Rex
- Re: [TLS] simplistic renego protection Simon Josefsson
- Re: [TLS] simplistic renego protection Stefan Santesson
- Re: [TLS] simplistic renego protection Stefan Santesson
- Re: [TLS] simplistic renego protection Eric Rescorla
- Re: [TLS] simplistic renego protection Eric Rescorla
- Re: [TLS] simplistic renego protection Michael D'Errico
- Re: [TLS] simplistic renego protection Michael D'Errico
- Re: [TLS] simplistic renego protection Michael D'Errico
- Re: [TLS] simplistic renego protection Martin Rex
- Re: [TLS] simplistic renego protection Marsh Ray
- Re: [TLS] simplistic renego protection Martin Rex
- Re: [TLS] simplistic renego protection Martin Rex
- Re: [TLS] simplistic renego protection David-Sarah Hopwood
- Re: [TLS] simplistic renego protection David-Sarah Hopwood
- Re: [TLS] simplistic renego protection David-Sarah Hopwood
- Re: [TLS] simplistic renego protection David-Sarah Hopwood
- Re: [TLS] simplistic renego protection David-Sarah Hopwood
- Re: [TLS] simplistic renego protection David-Sarah Hopwood
- Re: [TLS] simplistic renego protection Marsh Ray
- Re: [TLS] simplistic renego protection David-Sarah Hopwood
- Re: [TLS] simplistic renego protection Nasko Oskov
- Re: [TLS] simplistic renego protection Nelson B Bolyard
- Re: [TLS] simplistic renego protection Nelson B Bolyard
- Re: [TLS] simplistic renego protection Martin Rex
- Re: [TLS] simplistic renego protection Michael D'Errico
- Re: [TLS] simplistic renego protection Nelson B Bolyard
- Re: [TLS] simplistic renego protection Martin Rex
- Re: [TLS] simplistic renego protection David-Sarah Hopwood
- Re: [TLS] simplistic renego protection David-Sarah Hopwood
- Re: [TLS] simplistic renego protection David-Sarah Hopwood
- [TLS] Definition of "lenient server" David-Sarah Hopwood
- Re: [TLS] simplistic renego protection Stefan Santesson
- Re: [TLS] simplistic renego protection David-Sarah Hopwood
- Re: [TLS] simplistic renego protection Stefan Santesson
- Re: [TLS] simplistic renego protection Ben Laurie
- Re: [TLS] simplistic renego protection Stefan Santesson
- Re: [TLS] simplistic renego protection Bill Frantz
- Re: [TLS] simplistic renego protection David-Sarah Hopwood
- Re: [TLS] simplistic renego protection David-Sarah Hopwood
- Re: [TLS] simplistic renego protection Stefan Santesson
- Re: [TLS] simplistic renego protection Marsh Ray
- Re: [TLS] simplistic renego protection Martin Rex
- Re: [TLS] simplistic renego protection David-Sarah Hopwood
- Re: [TLS] simplistic renego protection Ben Laurie
- Re: [TLS] simplistic renego protection David-Sarah Hopwood
- Re: [TLS] simplistic renego protection Ben Laurie
- Re: [TLS] simplistic renego protection Pasi.Eronen
- Re: [TLS] simplistic renego protection Martin Rex
- Re: [TLS] simplistic renego protection Pasi.Eronen
- Re: [TLS] simplistic renego protection Yngve Nysaeter Pettersen
- Re: [TLS] simplistic renego protection Peter Gutmann
- Re: [TLS] simplistic renego protection Kyle Hamilton