Re: [TLS] No cypher overlap

Florian Weimer <fw@deneb.enyo.de> Sat, 01 August 2015 21:19 UTC

Return-Path: <fw@deneb.enyo.de>
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 86D1F1A1EFE for <tls@ietfa.amsl.com>; Sat, 1 Aug 2015 14:19:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.26
X-Spam-Level:
X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 zVFBT1B_9V2X for <tls@ietfa.amsl.com>; Sat, 1 Aug 2015 14:19:16 -0700 (PDT)
Received: from albireo.enyo.de (albireo.enyo.de [46.237.207.196]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E3C11A1C06 for <tls@ietf.org>; Sat, 1 Aug 2015 14:19:16 -0700 (PDT)
Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) id 1ZLeBW-00055i-Il; Sat, 01 Aug 2015 23:19:14 +0200
Received: from fw by deneb.enyo.de with local (Exim 4.84) (envelope-from <fw@deneb.enyo.de>) id 1ZLeBW-0006v9-FN; Sat, 01 Aug 2015 23:19:14 +0200
From: Florian Weimer <fw@deneb.enyo.de>
To: Viktor Dukhovni <ietf-dane@dukhovni.org>
References: <8087760.Ce9A43SzlW@pintsize.usersys.redhat.com> <20150728160154.GU4347@mournblade.imrryr.org>
Date: Sat, 01 Aug 2015 23:19:14 +0200
In-Reply-To: <20150728160154.GU4347@mournblade.imrryr.org> (Viktor Dukhovni's message of "Tue, 28 Jul 2015 16:01:55 +0000")
Message-ID: <87wpxezoz1.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/luNH82KHoUMMS_7Z2kQ_cJmO8-s>
Cc: tls@ietf.org
Subject: Re: [TLS] No cypher overlap
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <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: Sat, 01 Aug 2015 21:19:17 -0000

* Viktor Dukhovni:

> 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).

Or the server should negotiate TLS 1.2 instead.

Servers should already do something similar today: For an
extension-less TLS 1.2 handshake, they should negotiate TLS 1.1
instead, to get a stronger PRF.