Re: [TLS] Fixing TLS

Nikos Mavrogiannopoulos <> Wed, 13 January 2016 09:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B08501A0025 for <>; Wed, 13 Jan 2016 01:53:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3XMWRWdYnM60 for <>; Wed, 13 Jan 2016 01:53:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2536E1A0021 for <>; Wed, 13 Jan 2016 01:53:40 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPS id 857298CF5D; Wed, 13 Jan 2016 09:53:39 +0000 (UTC)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id u0D9ra7n009417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 13 Jan 2016 04:53:38 -0500
Message-ID: <>
From: Nikos Mavrogiannopoulos <>
To: Yoav Nir <>, Peter Gutmann <>
Date: Wed, 13 Jan 2016 10:53:36 +0100
In-Reply-To: <>
References: <> <>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on
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: Wed, 13 Jan 2016 09:53:41 -0000

On Tue, 2016-01-12 at 19:13 +0200, Yoav Nir wrote:
> Hi, Peter
> Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or
> 2.0) that this WG is working on right now, why?
> Other groups are not working on HTTP/1.2 or IKEv1.1 or any other
> $protocolv$(major-1).$(minor+1).

Note that these are not security protocols and they don't benefit from
a formal analysis of a protocol. Such an analysis takes several years
to be done and it often applies to small parts of the protocol.
Switching to a new version invalidates all the existing analysis.

That is of course not necessarily bad, but as we are moving towards
formally verified protocols it is very bad to give these two options:
1. Stay with a formally verified but with known vulnerabilities
2. Switch to a new unknown protocol which has not been studied by as
many cryptographers but is _believed_ to solve the issues found in TLS.

> Any TLS library that exists now doesn’t have an implementation of
> either “your” TLS 1.3 or “our” TLS 1.3. To get either, you’ll need to
> get an upgraded version of your favorite library. So the upgrade path
> is no smoother for either protocol.   If this had been brought up
> before the work on the current draft started, maybe we would be
> convinced. As it is, I don’t see the point.

The main problem of TLS 1.2 is that it is vulnerable to cross-protocol
attacks and there is no way to mitigate that. There was such an attack
described in 2012 and another in 2015 [0]. Whether there will be a new
one in 2017 is an open question. Switching to a protocol like TLS 1.3
as it is today to fix that thing it is an overkill.

That is because TLS 1.3 is a rewrite of the protocol, and requires a
rewrite of the code base. Given that the majority of the issues in TLS
implementations are in the code bases and not in the protocol, it is
very risky to switch to such a new version just like that. For old
systems it most likely will never happen and they will remain