Re: [TLS] simplistic renego protection
Eric Rescorla <ekr@networkresonance.com> Wed, 18 November 2009 08:02 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 CAC703A6858 for <tls@core3.amsl.com>; Wed, 18 Nov 2009 00:02:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 aGDIw9o+66Cw for <tls@core3.amsl.com>; Wed, 18 Nov 2009 00:02:19 -0800 (PST)
Received: from mail02.sov.host.iqunity.net (iqsexf02.sov.host.iqunity.net [84.233.227.93]) by core3.amsl.com (Postfix) with ESMTP id 7A16B3A63EB for <tls@ietf.org>; Wed, 18 Nov 2009 00:02:19 -0800 (PST)
Received: from kilo.networkresonance.com ([10.129.250.199]) by mail02.sov.host.iqunity.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 07:55:10 +0000
Received: from kilo.networkresonance.com ([10.64.254.35] helo=kilo.networkresonance.com) by ASSP.nospam; 18 Nov 2009 08:02:04 +0000
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 9D4FB69FC85; Wed, 18 Nov 2009 08:03:33 +0000 (GMT)
Date: Wed, 18 Nov 2009 08:03:33 +0000
From: Eric Rescorla <ekr@networkresonance.com>
To: Michael D'Errico <mike-list@pobox.com>
In-Reply-To: <4B038974.9080001@pobox.com>
References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> <4B02A084.9030903@cs.tcd.ie> <20091117175000.653E669FBC6@kilo.networkresonance.com> <4B038974.9080001@pobox.com>
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: <20091118080333.9D4FB69FC85@kilo.networkresonance.com>
X-Assp-Delay: not delayed (auto accepted); 18 Nov 2009 08:02:04 +0000
X-Assp-Received-DNSBL: pass
X-Assp-Received-URIBL: pass
X-Assp-Spam-Prob: 0.00000
X-Assp-Envelope-From: ekr@networkresonance.com
X-Assp-Intended-For: tls@ietf.org
X-OriginalArrivalTime: 18 Nov 2009 07:55:20.0481 (UTC) FILETIME=[79C90910:01CA6824]
Cc: tls@ietf.org
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: Wed, 18 Nov 2009 08:02:20 -0000
At Tue, 17 Nov 2009 21:43:16 -0800, Michael D'Errico wrote: > You forgot to mention: > > 4.3. SSLv3 > > SSLv3 does not support extensions and thus it is not possible to > securely renegotiate with SSLv3. Deployments wishing to renegotiate > securely will need to upgrade to at least TLS 1.0. > > Is there some secret agenda to kill off SSLv3? What is the point > of that? Well, I don't think it's a secret that many feel that it would be good for people to upgrade from SSLv3 to TLS. TLS includes a number of useful security fixes and extended functionality. So, it's not clear it's great to go out of our way to preserve its use indefinitely. With that said, I think that the quoted sentence is probably slightly too strong. There's no reason why extensions cannot be used with SSLv3, it's just that the IETF has no change control on SSLv3 and so it's kind of a matter of extrapolating 4366 to apply to the SSLv3 drafts. This is straightforward but undocumented. > SSLv3 accounts for more than one-in-five connections as > reported to this list. Well, I've seen this claimed, but I haven't seen a citation for where the data comes from. I'd be interested in seeing such a cite. The data I've seen (and posted) suggests that servers support TLS very widely, and certainly every piece of SSL/TLS-based software built on any even remotely modern stack includes support for TLS, whatever it chooses to negotiate. > There is an alternate proposal that does not > have this limitation, and is better in many other respects. Why do > you keep pushing this one? Because I feel that those other proposals are inferior in many other respects? I'm not sure why this is so hard for you to understand. -Ekr
- 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