Re: [TLS] Fixing TLS

"SCHWARZ, Albrecht (Albrecht)" <> Wed, 13 January 2016 10:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C4BB51A037B for <>; Wed, 13 Jan 2016 02:09:15 -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_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xhKSemG6wDBE for <>; Wed, 13 Jan 2016 02:09:13 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B35DD1A036B for <>; Wed, 13 Jan 2016 02:09:13 -0800 (PST)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id BB791128BF909 for <>; Wed, 13 Jan 2016 10:09:08 +0000 (GMT)
Received: from ( []) by (GMO) with ESMTP id u0DA944l012958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <>; Wed, 13 Jan 2016 11:09:10 +0100
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Wed, 13 Jan 2016 11:09:05 +0100
From: "SCHWARZ, Albrecht (Albrecht)" <>
To: "<>" <>
Thread-Topic: [TLS] Fixing TLS
Thread-Index: AQHRTehT2rYBdeSLgEifQoT+VaXxrp75N4MA
Date: Wed, 13 Jan 2016 10:09:04 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Wed, 13 Jan 2016 10:09:15 -0000

> Switching to a protocol like TLS 1.3 as it is today to fix that thing it is an overkill.

The primary purpose of a security protocol is to support security as best as possible. Knowing security gaps causes distrust in general. Probably not in the security protocol experts community, but in the overall communications and information technology industry.
The quantification of "overkill" should be rated from that trust perspective in my opinion.


-----Original Message-----
From: TLS [] On Behalf Of Nikos Mavrogiannopoulos
Sent: Mittwoch, 13. Januar 2016 10:54
To: Yoav Nir; Peter Gutmann
Cc: <>
Subject: Re: [TLS] Fixing TLS

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 protocol 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 vulnerable.



TLS mailing list