Re: [TLS] Fixing TLS

Ilari Liusvaara <> Thu, 14 January 2016 10:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 05E0D1B32BB for <>; Thu, 14 Jan 2016 02:29:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Yq6_XIzK61dH for <>; Thu, 14 Jan 2016 02:29:38 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 63F751B32BA for <>; Thu, 14 Jan 2016 02:29:37 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85CB52375; Thu, 14 Jan 2016 12:29:36 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id XlSbdCBiUKZU; Thu, 14 Jan 2016 12:29:36 +0200 (EET)
Received: from LK-Perkele-V2 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 45BE527B; Thu, 14 Jan 2016 12:29:36 +0200 (EET)
Date: Thu, 14 Jan 2016 12:29:33 +0200
From: Ilari Liusvaara <>
To: Martin Rex <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Fixing TLS
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: Thu, 14 Jan 2016 10:29:41 -0000

On Thu, Jan 14, 2016 at 10:40:44AM +0100, Martin Rex wrote:
> Ilari Liusvaara wrote:
> >
> > To actually fix the known problems with TLS 1.2, you would at minimum
> > need a new extension, since there is currently no way to fix the broken
> > server authentication.
> One Boolean signaling is sufficent to fix all of the problems.
> one SCSV in the Client->Server direction and a TLS extension Boolean
> response in ServerHello.

Just stick it as an extension. Extensions have been required since TLS
1.0, its precessor SSL 3.0 is _dead_. And extension-intolerant servers
are just plain problems for everybody.

> > 
> > Then there are the other security fix extensions (at least three already).
> > Those all would need to be impiled.
> > 
> > And then there is the TLS 1.2 Diffie-Hellman issue...
> TLS 1.2LTS should fix them all at once, including:
>    - promise to support minimum DHE key lengths >= 2048 bits
>      whenever ClientHello includes DHE cipher suites

The problem is that client that tries to be secure will just abort
if it receives DHE <2048 bits. Regardless if server accepted the
extension or not.

Then there's also similar problems with RSA. And then RSA PKCS #1
v1.5 encryption is on just about every "do not use!" list. Get it
wrong (good luck getting it right) and it is game over.

>    - promise to support a certain small subset of EC curves
>      and uncompressed point format whenever ClientHello includes
>      ECDHE cipher suites (but may omit TLS extensions).

You have EC formats extension already.

Or do you mean that there are broken endpoints that can't mix-and-
match ECDHE curves and signatures?

(I know about problems doing mix-and-match on hashes and curves
in ECDSA... TLS has currently no way to signal those limits).
>    - new/improved ServerKeyExchange handshake message, which
>      does not only contain the reasonable set of DHE parameters,
>      but also uses a digititally signed covering all prior
>      handshake messages, not just the two hello randoms.

You mean fixing the DHE groups? Because the present arbitrary groups
are source of many problems.

This also causes problems for anyone trying to support DHE in TLS 1.3.

>    - overriding any TLS record layer protocol version and
>      ClientHello.client_version that is less than TLSv1.2
>    - promise that digital signatures using SHA-256 are supported

You mean upgrade the default SHA-1 to SHA-256?

>    - fix the misunderstood semantics of the signature_algorithm extension
>      so that it is only used as a hint to certificate selection,
>      but *NEVER* seen as a hard requirement (or reason for server to
>      abort the TLS handshake based on the signature of the server cert).

The client aborts if server certificate chain won't validate due to
bad algorithms, right?

And then:

- Imply Extended Master Secret.

- Require Renego fixes.

- Imply EtM on block modes.

(Any others?)