Re: [TLS] No cypher overlap (was: ban more old crap)

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 28 July 2015 16:02 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B301ACD6D for <tls@ietfa.amsl.com>; Tue, 28 Jul 2015 09:02:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWNbmOdNYG8g for <tls@ietfa.amsl.com>; Tue, 28 Jul 2015 09:01:57 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8BD91ACD60 for <tls@ietf.org>; Tue, 28 Jul 2015 09:01:56 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9C47D284B64; Tue, 28 Jul 2015 16:01:55 +0000 (UTC)
Date: Tue, 28 Jul 2015 16:01:55 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150728160154.GU4347@mournblade.imrryr.org>
References: <8087760.Ce9A43SzlW@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8087760.Ce9A43SzlW@pintsize.usersys.redhat.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/e3dAZEczROFh77ao_fWsnyETBpE>
Subject: Re: [TLS] No cypher overlap (was: ban more old crap)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
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: <https://mailarchive.ietf.org/arch/browse/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, 28 Jul 2015 16:02:01 -0000

On Tue, Jul 28, 2015 at 05:41:58PM +0200, Hubert Kario wrote:

> I see one possible problem with TLS1.3 not being a superset of TLS1.2.
> 
> Consider the following:
> Server which supports TLSv1.3 but is configured to accept only AES256 
> ciphers.
>
> Client which advertises TLSv1.3, but no support for AES256-GCM. The client 
> advertises also CBC ciphers (both AES128 and AES256) as it wants to be able
> to connect to legacy servers too.
> 
> Should such a connection end up with TLS1.2 with AES-CBC ciphersuite, or 
> should it be aborted?

We already see a similar dilemma with clients that (artificially)
support only SSLv2 ciphersuites, but advertise TLS protocol versions.
OpenSSL will first choose a common protocol (TLS 1.x) and then fail
to find any shared ciphers.  To complete the connection, the client
must explicitly request only SSL 2.0.  There is at present no
filtering out of protocol choices for lack of compatible ciphers.

> I think we should go for continue connection with downgraded protocol, but 
> explicitly say that it may not happen if the negotiated ciphersuite would be 
> DES, RC4, export grade...

In that case, it should be said that a client MUST NOT advertise
TLS 1.3 unless it offers at least one of the TLS 1.3 MTI ciphers
(or perhaps less restrictive at least one TLS 1.3 compatible cipher).

Otherwise, there'll be lots of clients whose TLS libraries advertise
1.3 (just because they implement the protocol), but whose cipher
configuration includes only TLS 1.2 (or lower) suites (because the
application configuration has not been updated).

Punishing those clients by having servers abort the handshake is
a bad idea.  The right outcome is use of TLS 1.2, whether because
client implementations of 1.3 need to check that adequate cipher
suites are available, or because servers negotiate 1.2 when 1.3
is impossible.

-- 
	Viktor.