Re: [TLS] simplistic renego protection
David-Sarah Hopwood <david-sarah@jacaranda.org> Mon, 16 November 2009 19:31 UTC
Return-Path: <djhopwood@googlemail.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 BBAEE28C20E for <tls@core3.amsl.com>; Mon, 16 Nov 2009 11:31:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 VdLChUOOLHn7 for <tls@core3.amsl.com>; Mon, 16 Nov 2009 11:31:10 -0800 (PST)
Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 72E6228C20C for <tls@ietf.org>; Mon, 16 Nov 2009 11:31:10 -0800 (PST)
Received: by fxm7 with SMTP id 7so6131953fxm.29 for <tls@ietf.org>; Mon, 16 Nov 2009 11:31:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=L/QasDaQfKxIGbTuoSucv7SY/0CxuNhb93TTxLLQ6tI=; b=bI2BrSOGbxWPS6lUL5exhYUiBxOP+YqLQmCeEmZwJkse9Tn+5sueHr/4wu0+4wbZGU UWum8iyzUiLaBf48wEDnaLkWmSZuI0Ki8V04jjA5y9x6CCeEtKUMYDL/2e9lIJIyQv9z PG2wPdHlraVX6DTkRvYjbicaYNrio/FTqThWw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=PpqPjCSdRB1kOTERw49vOY2Y9zVrtDKT5yPNyJiErolLSXKEhG4sAIK3dEBjppfXL2 0TxVO2cpGN9S6o/BxY0gQjj7qMuDhYL+1mrDuvRyq5xqK3djvCwqsRa8jGEBdnYPuEYz E7bKNTnitrt/JsxKMf7K4Kr+wAODxJAeIT9Aw=
Received: by 10.102.160.15 with SMTP id i15mr3838047mue.130.1258399865376; Mon, 16 Nov 2009 11:31:05 -0800 (PST)
Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id j6sm731869mue.20.2009.11.16.11.31.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 11:31:04 -0800 (PST)
Sender: David-Sarah Hopwood <djhopwood@googlemail.com>
Message-ID: <4B01A872.1010509@jacaranda.org>
Date: Mon, 16 Nov 2009 19:30:58 +0000
From: David-Sarah Hopwood <david-sarah@jacaranda.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: tls@ietf.org
References: <200911161405.nAGE5Vql002016@fs4113.wdf.sap.corp>
In-Reply-To: <200911161405.nAGE5Vql002016@fs4113.wdf.sap.corp>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------enig754197D11C42EE032397F51E"
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: Mon, 16 Nov 2009 19:31:11 -0000
Martin Rex wrote: > Do you realize how much implementation and testing is involved when > shipping the fix as a TLS extension. Yes. Are you suggesting that a fix that uses some other ad hoc signalling mechanism does not need to undergo thorough interoperability testing? > If someone with an old server, who doesn't implement renegotiation and > TLS extensions wants to add this patch, he will need to add the entire > TLS extensions handling in a generic fashion and require a significantly > larger interop testing scenario to make sure that it acutally works: If a server doesn't implement renegotiation, then it is already as secure as it can be with respect to this attack. The server only needs to be patched so that strict clients will recognize it as patched. To achieve that, the server clearly must signal something in a message that it sends. If that is not done using an extension, then it must be done using another mechanism such as recognizing a magic ciphersuite and stuffing its response in some covert channel (which I cannot believe we are even seriously discussing, frankly). Remember, complicated kludges such as fallback to accomodate broken server implementations are only needed, if they are needed at all, on the client side. Implementing extensions on the server side is completely trivial. Many server implementors have already done that work, whereas *no* server implementors have done the work to support any newly invented signalling mechanism. > You're going to waste network bandwith eternally in a completely > useless fashion. The bandwidth usage is completely insignificant, even for highly constrained environments. If I've calculated correctly, the size of the extension is 5 bytes in each direction in the most common, non-renegotiating case (17 or 29 bytes when renegotiating), and it adds no round-trips. Compare that to X.509 certificate sizes, which are typically at least 1 KiB each. -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
- 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