Re: [TLS] TLS renegotiation issue

Nagendra Modadugu <ngm+ietf@google.com> Sun, 08 November 2009 20:51 UTC

Return-Path: <ngm@google.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 102C93A683A for <tls@core3.amsl.com>; Sun, 8 Nov 2009 12:51:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level:
X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 6N1x2-7uzCQ1 for <tls@core3.amsl.com>; Sun, 8 Nov 2009 12:51:39 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id E4A843A6768 for <tls@ietf.org>; Sun, 8 Nov 2009 12:51:38 -0800 (PST)
Received: from spaceape11.eur.corp.google.com (spaceape11.eur.corp.google.com [172.28.16.145]) by smtp-out.google.com with ESMTP id nA8Kq3nJ011362 for <tls@ietf.org>; Sun, 8 Nov 2009 12:52:03 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257713524; bh=LOvOmtWslRi1N9yn9VnpW9zAG6o=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Nuyomirm3vSBhtOISW53qorT5EvzIsA5yfoABMLhefTQhEbOcWZyrkcuJDVQqmiaq 8anwl3fpb2VcnXthMBNnw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=uxwqsjYnSp+tB3ZH63q5Upr/3qFAUJEyPNwb58X2Unct5LLxSIpJwSYRX0S0b4hdR 0D7KkdZsWzQ8rmqc68OxQ==
Received: from pxi26 (pxi26.prod.google.com [10.243.27.26]) by spaceape11.eur.corp.google.com with ESMTP id nA8Kpwao024445 for <tls@ietf.org>; Sun, 8 Nov 2009 12:52:00 -0800
Received: by pxi26 with SMTP id 26so1508655pxi.21 for <tls@ietf.org>; Sun, 08 Nov 2009 12:51:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.142.7.10 with SMTP id 10mr743836wfg.137.1257713518546; Sun, 08 Nov 2009 12:51:58 -0800 (PST)
In-Reply-To: <d3aa5d00911051016p7a0cc508q2090b86de30a50d5@mail.gmail.com>
References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <d3aa5d00911051016p7a0cc508q2090b86de30a50d5@mail.gmail.com>
Date: Sun, 8 Nov 2009 12:51:58 -0800
Message-ID: <28425e380911081251j48a1065fv98e782aecf9f7ffc@mail.gmail.com>
From: Nagendra Modadugu <ngm+ietf@google.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary=00504502aca58091d40477e23f79
X-System-Of-Record: true
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 20:51:40 -0000

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
>