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