Re: [TLS] One approach to rollback protection

Juho Vähä-Herttua <juhovh@iki.fi> Tue, 27 September 2011 07:01 UTC

Return-Path: <juhovh@iki.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A8521F8E22 for <tls@ietfa.amsl.com>; Tue, 27 Sep 2011 00:01:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0BTbYKarMxT for <tls@ietfa.amsl.com>; Tue, 27 Sep 2011 00:01:01 -0700 (PDT)
Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 90F8E21F8E20 for <tls@ietf.org>; Tue, 27 Sep 2011 00:01:01 -0700 (PDT)
Received: from mail.visino.fi (88.192.37.90) by jenni1.inet.fi (8.5.133) id 4E7C5E0F002B523C; Tue, 27 Sep 2011 10:03:43 +0300
Received: from [192.168.1.100] (dsl-hkibrasgw3-ff2cc000-252.dhcp.inet.fi [88.192.44.252]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: juhovh) by mail.visino.fi (Postfix) with ESMTPSA id 2B7781FEE1; Tue, 27 Sep 2011 10:03:41 +0300 (EEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= <juhovh@iki.fi>
In-Reply-To: <4E81293A.4000402@extendedsubset.com>
Date: Tue, 27 Sep 2011 10:03:40 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <2F31D195-9533-4580-8681-8E8FF6610AC3@iki.fi>
References: <201109270021.p8R0LXMQ012210@fs4113.wdf.sap.corp> <4E81293A.4000402@extendedsubset.com>
To: Marsh Ray <marsh@extendedsubset.com>
X-Mailer: Apple Mail (2.1084)
Cc: tls@ietf.org
Subject: Re: [TLS] One approach to rollback protection
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Tue, 27 Sep 2011 07:01:02 -0000

On Sep 27, 2011, at 4:39 AM, Marsh Ray wrote:
> I agree that the current semantics are starting to feel a bit silly. Support for TLS 1.2 also implies a willingness to speak SSLv3?
> Are we expecting to continue this forever?

How come support for TLS 1.2 also implies a willingness to speak SSLv3? I don't see that in the specification.

> On 09/26/2011 08:14 PM, Eric Rescorla wrote:
> > In an environment where the client could indicate any combination of
> > versions, the impact of implementing TLS 1.2 only would be that a
> > server which did not support TLS 1.2 would generate an error instead
> > of a ClientHello. [ServerHello?]
> >
> > Since servers are supposed to select the highest common version, I'm
> > not sure I see serious difference between these two.
> 
> The difference is that somebody will look at Wireshark and instead of seeing random disconnects and thinking they're the subject of some low-level DoS attack, they'll see a bright yellow line that reads:
> "TLS Alert: Endpoints support no common protocol version."

There is already a protocol_version alert, which is supposed to have exactly this meaning. If the client sends a lower version than the lowest supported server version in ClientHello, server replies with protocol_version alert. If the server sends a lower version than the lowest supported client version in ServerHello, client replies with protocol_version alert. Only problem here is that the version negotiation is broken in implementations, not that it doesn't work in theory...

The problem I believe Martin was trying to point out is a hypothetical case where a client for example supports TLS 1.1, TLS 1.2 and SSLv3 for backwards compatibility, but not TLS 1.0. When it connects to a server which supports SSLv3 and TLS 1.0 only, the server will most likely reply with TLS 1.0 in ServerHello. Now the client can only reply with protocol_version to indicate no common protocol version was supported, even though in fact SSLv3 handshake would have succeeded. Only way to fix this properly would be to explicitly list all supported versions in the ClientHello.

The suggestion brought up by Eric could make this possibly with only slight modifications, but then it would effectively override the current version negotiation. I can easily see a scenario where all implementations send TLS 1.0 in ClientHello and send all higher supported versions as cipher suites. That would be ugly, and I hate abusing the cipher suites for renegotiation and now this, but I have to admit it would solve a lot of problems...

About the current proposal by Eric I have to agree with Martin, it is a hack that only increases handshake failures without helping in any way with the current version negotiation problems. Implementing a proposal like that doesn't make much sense to me.


Juho