IETF Logo Mail Archive

Re: [TLS] simplistic renego protection

Eric Rescorla <ekr@networkresonance.com> Wed, 18 November 2009 16:00 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 33C5428C0EF for <tls@core3.amsl.com>; Wed, 18 Nov 2009 08:00:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.801
X-Spam-Level: *
X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, MANGLED_TOOL=2.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.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 3ny6LSfEsl+M for <tls@core3.amsl.com>; Wed, 18 Nov 2009 08:00:07 -0800 (PST)
Received: from kilo.networkresonance.com (cpc2-oxfd20-2-0-cust889.4-3.cable.virginmedia.com [86.26.27.122]) by core3.amsl.com (Postfix) with ESMTP id 94DF028C112 for <tls@ietf.org>; Wed, 18 Nov 2009 08:00:06 -0800 (PST)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id E8B5C69FE20; Wed, 18 Nov 2009 15:43:53 +0000 (GMT)
Date: Wed, 18 Nov 2009 15:43:53 +0000
From: Eric Rescorla <ekr@networkresonance.com>
To: Simon Josefsson <simon@josefsson.org>
In-Reply-To: <87skcbyjxg.fsf@mocca.josefsson.org>
References: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> <4B022EBB.5030108@pobox.com> <808FD6E27AD4884E94820BC333B2DB774F30FE106F@NOK-EUMSG-01.mgdnok.nokia.com> <87skcbyjxg.fsf@mocca.josefsson.org>
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: <20091118154353.E8B5C69FE20@kilo.networkresonance.com>
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 16:00:08 -0000

At Wed, 18 Nov 2009 15:41:31 +0100,
Simon Josefsson wrote:
> 
> <Pasi.Eronen@nokia.com> writes:
> 
> > It seems many of the drawbacks of tls-renegotiation-00 you mention 
> > are in fact addressed (to some degree) in version -01? (mainly
> > by including the "magic cipher suite") Compared to -01, what do
> > you think the main differences are?
> 
> As far as I can tell, -01 does not fix (*) the problem for
> clients/servers that uses
> 
>    a) a SSLv3 implementation, or
>    b) a original TLSv1 implementation (e.g., RFC 2246), or
>    c) a TLSv1.1 implementation without support for extensions.
> 
> Providing a solution only for the latest version of TLS is akin to ask
> people to upgrade to the latest release of a particular software rather
> than provide a simple fix to the existing deployed software.

I really don't understand this argument. Extensions are completely
compatible with TLS 1.0, 1.1, and as has been observed by
Martin, compatible in principle with SSLv3. Any fix will require
some changes to people's software. I don't see how that consists
at all of providing a solution only for the latest version of
TLS.

-Ekr

v2.23.0 | Report a Bug | By Email