Re: [TLS] To extend or not to extend

Eric Rescorla <ekr@networkresonance.com> Sun, 15 November 2009 23:45 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 9798F3A6A33 for <tls@core3.amsl.com>; Sun, 15 Nov 2009 15:45:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.153
X-Spam-Level:
X-Spam-Status: No, score=-0.153 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, 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 ZHRU-hu-pFLj for <tls@core3.amsl.com>; Sun, 15 Nov 2009 15:45:31 -0800 (PST)
Received: from genesis-hsia.quadriga-www.com (2.26.235.80.sta.estpak.ee [80.235.26.2]) by core3.amsl.com (Postfix) with ESMTP id A1C723A6765 for <tls@ietf.org>; Sun, 15 Nov 2009 15:45:31 -0800 (PST)
Received: from [192.168.12.187] (helo=kilo.networkresonance.com) by genesis-hsia.quadriga-www.com with esmtp (Exim 3.34 #1) id 1N9oT5-0002T8-00 for tls@ietf.org; Mon, 16 Nov 2009 01:25:15 +0200
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 0DADD69F838; Mon, 16 Nov 2009 01:26:31 +0200 (EET)
Date: Mon, 16 Nov 2009 01:26:31 +0200
From: Eric Rescorla <ekr@networkresonance.com>
To: Nelson B Bolyard <nelson@bolyard.me>
In-Reply-To: <4B006F37.6030905@bolyard.me>
References: <AC1CFD94F59A264488DC2BEC3E890DE5091A760A@xmb-sjc-225.amer.cisco.com> <20091115113857.4E04D69F7B2@kilo.networkresonance.com> <4B006F37.6030905@bolyard.me>
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: <20091115232632.0DADD69F838@kilo.networkresonance.com>
Cc: tls@ietf.org
Subject: Re: [TLS] To extend or not to extend
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, 15 Nov 2009 23:45:32 -0000

At Sun, 15 Nov 2009 13:14:31 -0800,
Nelson B Bolyard wrote:
> 
> On 2009-11-15 03:38 PDT, Eric Rescorla wrote:
> 
> > So, thinking further on my earlier message, I think the following 
> > elaboration will work a bit better:
> > 
> > - Strict clients (those which wish to insist on RI) generate RI on
> >   initial handshake. As I said earlier, I don't think this is
> >   useful, but it works.
> > 
> > - Lenient clients do not generate RI on initial handshake but do
> >   generate it on rehandshake with TLS 1.0+ only. 
> >   + Moderately lenient clients can fail if the server does not
> >     do RI.
> >   + Really lenient clients can ignore the server's failure to
> >     do RI.
> 
> Aren't your so-called Lenient clients still 100% vulnerable to the attack?
> 
> What prevents their initial handshakes from being used by an attacker as
> renegotiations with a vulnerable server?

Absolutely nothing. As far as I know, the only way to avoid that is to
refuse to connect to any server that you can't verify is upgraded,
which, at least for the moment, is basically the same as saying you
can't connect with a very substantial fraction of the Internet. It
might well be possible to probe as you suggest in a subsequent
message, but I don't think there's going to be a good way inside
TLS...

-Ekr