Re: [TLS] Fixing TLS

Ilari Liusvaara <> Tue, 12 January 2016 17:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 885071A00BB for <>; Tue, 12 Jan 2016 09:17:15 -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 6vWoGEC0asXW for <>; Tue, 12 Jan 2016 09:17:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4B67A1A00A8 for <>; Tue, 12 Jan 2016 09:17:12 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 05F43467 for <>; Tue, 12 Jan 2016 19:17:10 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id FqkqmmgejqdJ for <>; Tue, 12 Jan 2016 19:17:09 +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 AF603138 for <>; Tue, 12 Jan 2016 19:17:09 +0200 (EET)
Date: Tue, 12 Jan 2016 19:17:06 +0200
From: Ilari Liusvaara <>
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: <>
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: Tue, 12 Jan 2016 17:17:15 -0000

On Tue, Jan 12, 2016 at 02:03:53PM +0000, Peter Gutmann wrote:
> Martin's comment reminded me of the following that I've been meaning to
> post...
> In a recent discussion among some crypto folks, the topic of what TLS 1.3
> could be came up.  Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path from
> TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is.  The discussion
> centered around the fact that we already have lots of analysis done for TLS
> 1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3
> problems while being as compatible as possible with existing infrastructure.
> So what this would do is take existing security analysis applied to TLS,
> namely:

Don't forget that there is lots of "features" that are security
problems to deprecate. And that alone creates problems with software
trying to use those.
> (and probably several more) and use them to simplify TLS 1.2 to create an
> improved TLS that leverages about 15 years of analysis, rather than creating
> what's almost a new protocol based on bleeding-edge/experimental ideas,
> mechanisms, and algorithms.

Bleeding edge ideas? They essentially re-invented SIGMA, which is over
10 years old. The basic framework for doing 0-RTT is the obvious one.
The only new algorithm prsent since TLS 1.2 is HKDF, which is just 5
years old. 

So I don't see anything "experimential" ideas, mechanisms or algorithms
in there
> The discussion started out somewhat informally so by the time it got really
> interesting it was too late to take notes, but I thought I'd try and recreate
> the design points...
> - Drop 99% of all cipher suites, leaving one traditional one (DHE + AES-CBC +
>   HMAC-SHA2 + RSA-SHA2/PSK for auth) and one ECC one (ECDHE + AES-GCM + HMAC-
>   SHA2 + ECDSA-SHA2/PSK for auth) as must's (with a strong preference for OCB
>   instead of GCM as the AEAD if it were freely available).

DHE has serious problems. While the present TLS 1.3 way of doing DHE
isn't totally horrible, advertise DHE and you can get downnegotiation to
TLS 1.2 DHE, and now you are screwed.

Also, AES-CBC has multitude of problems. And they actually dropped most of
the ciphersuites.

> - For the non-AEAD cipher, use EtM not MtE (so effectively making it AEAD as
>   well).

Easier to define everything in terms of AEAD mode. Making generic
composition AES-CBC+HMAC-SHA2 isn't as easy as it seems (even pro
cryptographers may not get that right).

> - Get rid of the IPsec cargo-cult MAC truncation.

Finished hashes are no longer truncated (which turned to be a security 
> - For DHE, send the full set of parameters (X9.42), not p+g only (PKCS #3) to
>   allow verification (for those who don't have a copy of X9.42, it requires
>   the same verification steps as FIPS 186 does).  Also, mix the hash of the
>   DHE values into the computed premaster secret to protect against use of
>   manipulated curves.

The needed checks at that length are just too slow for realtime.

> - RSA-PSS, not PKCS #1 (with a subset arguing for PKCS #1 with the sig-check
>   done as encode-then-compare, which fixes all known padding-manipulation
>   issues).

Well, the server sig for RSA is RSA-PSS (the recommendation about encode-
and-compare isn't the tho).

> - No compression or rehandshake.

They dropped those.

> - Replace the PRF with HKDF?  (No pressing need for this, but it would be part
>   of the general cleanup).

They replaced it with just that.

> Longer discussion points:
> - The DHE/ECDHE parameters were a bit contentious.  For DHE the choice is
>   between server-specified ephemeral parameters and IETF-blessed fixed ones.
>   Arguments can be made either way, we had de facto IETF-blessed fixed DHE
>   params in the form of the RFC 2409 ones, but that wasn't such a good idea.
>   OTOH with ephemeral DHE params many implementations didn't check them, but
>   then the spec never required any checking (or much of anything at all in
>   regard to DHE use, which no doubt contributed to some of the dubious
>   practices that have been found in the wild).  The situation wasn't helped by
>   the use of the PKCS #3 representation, which the requirement to use the
>   X9.42 form alongside the accompanying checks attempts to address.

Dubious? I would say downright insecure (including some I would say F
grade in SSL labs is too generous).

> - Similarly, for ECDHE the choice is between NIST and CFRG ones.  The CFRG
>   ones are obviously better (for various values of better, see endless debates
>   elsewhere), but some people will insist on only using something that's come
>   from NIST (I'll reserve my opinion on that one, and wouldn't dream of
>   stooping to phrases like "cargo cult protocol design"...).

There's also Brainpool (if you want to burn CPU, those are just
inefficient). :-)