Re: [TLS] No cypher overlap (Martin Rex) Sun, 02 August 2015 14:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 477151A8761 for <>; Sun, 2 Aug 2015 07:35:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.651
X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FPLYd4iuhgnH for <>; Sun, 2 Aug 2015 07:35:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 27F391A1B77 for <>; Sun, 2 Aug 2015 07:35:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F36D44796; Sun, 2 Aug 2015 16:35:43 +0200 (CEST)
X-purgate-ID: 152705::1438526143-0000413A-71D365DC/0/0
X-purgate-size: 2481
X-purgate: clean
X-purgate: This mail is considered clean (visit for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R)
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ( []) by (Postfix) with ESMTP id 10F8A40A23; Sun, 2 Aug 2015 16:35:43 +0200 (CEST)
Received: by (Postfix, from userid 10159) id 05C621A21C; Sun, 2 Aug 2015 16:35:43 +0200 (CEST)
In-Reply-To: <>
To: Florian Weimer <>
Date: Sun, 02 Aug 2015 16:35:42 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
Archived-At: <>
Subject: Re: [TLS] No cypher overlap
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 02 Aug 2015 14:35:48 -0000

Florian Weimer wrote:
> * 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.

The facts and reasoning in this short statement is flawed.

The TLSv1.2 PRF uses SHA256 throughout, and the hash of the PRF in TLS
is *NOT* negotiated through extensions, but through TLS cipher suites
(which do not need extensions).

TLSv1.2 has exactly one mandatory to implement ciphersuite:


and this cipher suite works perfectly fine without TLS extensions,
and will be used with a SHA-1 PRF for TLSv1.0 & TLSv1.1 and with a
SHA-256 PRF with TLSv1.2.

The highest security level (in the NIST SP800-57 part1 sense) that
you can get with this cipher suite is the equivalent of 128-bit
-- but that requires that you use server certificates with
RSA keys of at least 3072-bit.  The most commonly used server
certificates today use 2048-bit RSA keys and limit the security to

The use of a SHA-1 PRF in TLSv1.0 and TLSv1.1 is perfectly OK with
NIST SP800-57 part1 for 128-bit security.

The "weakness" of extension-less TLSv1.2 affects only the
the weakened digitally-signed transform and the behaviour suggested
in rfc5246 section for the absence of the signature_algorithms
extension, and the incredibly behaviour that some implementations

In the history of TLS RFCs there are two examples of completely botched
descriptions of default behaviour for a TLS extension when it is not sent.

The first extreme is in the informational document rfc4492 (TLS cipher
suites with Elliptic Curves), where it says, when the extension is
absent, assume that the peer supports *EVERYTHING*.  The opposite
extreme nonsense is what TLSv1.2 describes for the TLSv1.2 signature
extension when the extension is not sent, because it suggest a 
braindead self-limitation to an algorithm that had already been
deprecated and end-of-lifed with only 2 years left when TLSv1.2
was published, and no such limitation exists in earlier TLS versions.