Re: [TLS] TLS renegotiation issue

Eric Rescorla <ekr@rtfm.com> Sun, 08 November 2009 22:23 UTC

Return-Path: <ekr@rtfm.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 87EB128C0DE for <tls@core3.amsl.com>; Sun, 8 Nov 2009 14:23:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 xp79ZzIo25gy for <tls@core3.amsl.com>; Sun, 8 Nov 2009 14:23:19 -0800 (PST)
Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 717783A6358 for <tls@ietf.org>; Sun, 8 Nov 2009 14:23:19 -0800 (PST)
Received: by ywh13 with SMTP id 13so2716907ywh.29 for <tls@ietf.org>; Sun, 08 Nov 2009 14:23:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.90.10.9 with SMTP id 9mr605799agj.69.1257719019814; Sun, 08 Nov 2009 14:23:39 -0800 (PST)
In-Reply-To: <28425e380911081251j48a1065fv98e782aecf9f7ffc@mail.gmail.com>
References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <d3aa5d00911051016p7a0cc508q2090b86de30a50d5@mail.gmail.com> <28425e380911081251j48a1065fv98e782aecf9f7ffc@mail.gmail.com>
Date: Sun, 8 Nov 2009 14:23:39 -0800
Message-ID: <d3aa5d00911081423k3361abb1u31b166e248e4e799@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: Nagendra Modadugu <ngm+ietf@google.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS renegotiation issue
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: Sun, 08 Nov 2009 22:23:20 -0000

interesting point, but let me suggest another view:

The empty renegotiation extension used on an initial renegotiation says:

1. I support this extension.
2. This is an initial negotiation.

Now, it's not important to the server to know that the client supports the
extension. Any renegotiation without the extension is automatically
suspect. And the client can only use the lack of support to terminate
servers if it's willing to break almost all compatibility, in which case
TLS only isn't a problem.

This leaves us with the second purpose, but that's accomplished just
as well by having SSL3/TLS clients offer SSL3 client hello with the
TLS version number and then offering the extension on renegotiation
only.

Does that address your issue?
-Ekr




On Sun, Nov 8, 2009 at 12:51 PM, Nagendra Modadugu <ngm+ietf@google.com>; wrote:
>
> SSL3 is still in wide use since it is not considered insecure (other than
> the renegotiation issue).  Is it feasible to explicitly deprecate SSL3?  Or
> state that renegotiation support for SSL3 is deprecated?
>
> Here is the rationale.  Clients that have both SSL3/TLS1 enabled will send a
> 'mixed-type' SSL3/TLS1 ClientHello (i.e. Record.version = 3.0,
> ClientHello.version = 3.1).  Such clients should, strictly speaking, not
> include TLS extensions, which means that renegotiation should not be allowed
> by the server regardless of the protocol version negotiated.  Considering
> that a majority of clients will continue to support both SSL3 and TLS1 for
> some time (as a practical matter), the new extension will not come into
> effect unless clients (a) cease sending mixed-type ClientHello messages, or
> (b) send TLS extensions even when Record.version = 3.0.
>
> Option (a) leaves open the possibility for down-grade attacks (i.e. a MITM
> blocks TLS1 connections, allowing clients to reconnect over SSL3 -- I recall
> that atleast one major browser will attempt to reconnect over SSL3 if a
> TLS1, or mixed-type handshake fails).  Option (b) requires extension support
> to be "back-ported" to SSL3.
>
> I suggest that the draft discourage the use of SSL3 entirely.
>
> On Thu, Nov 5, 2009 at 10:16 AM, Eric Rescorla <ekr@rtfm.com>; wrote:
>> I now have a draft extension up at:
>>
>>
>> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt
>>
>> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.xml
>>
>> Comments welcome.
>>
>> -Ekr
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>