[TLS] The future devices that will break TLS 1.4

Hanno Böck <hanno@hboeck.de> Fri, 12 January 2018 23:02 UTC

Return-Path: <hanno@hboeck.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 68D01127342 for <tls@ietfa.amsl.com>; Fri, 12 Jan 2018 15:02:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id at-NpfUqFd7S for <tls@ietfa.amsl.com>; Fri, 12 Jan 2018 15:02:10 -0800 (PST)
Received: from zucker2.schokokeks.org (zucker2.schokokeks.org []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC8FE12711B for <tls@ietf.org>; Fri, 12 Jan 2018 15:02:09 -0800 (PST)
Received: from pc1 (178-83-154-183.dynamic.hispeed.ch [::ffff:]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Sat, 13 Jan 2018 00:03:09 +0100 id 0000000000000028.000000005A593EAD.0000305F
Date: Sat, 13 Jan 2018 00:02:06 +0100
From: Hanno =?UTF-8?B?QsO2Y2s=?= <hanno@hboeck.de>
To: tls@ietf.org
Message-ID: <20180113000206.6bc36af6@pc1>
X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/KP_e541yxrpHAnkO35NyVS1cyoc>
Subject: [TLS] The future devices that will break TLS 1.4
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jan 2018 23:02:18 -0000


This working group just went through a painful process of realizing
that deploying a new TLS version on the Internet is a hard task due to
broken devices. If you're not aware David Benjamin just gave a great
talk summarizing the issues:

Today I found this article:

tl;dr Cisco now says they can identify malware in TLS traffic by
carefully looking at it.
(For context: devices from Cisco were responsible for many of the
issues that made deploying TLS 1.3 hard, e.g. version intolerance on
load balancers and recently by not correctly terminating TLS in a

I'll dare to have a look into the future and make this imho very
plausible claim:
Cisco won't be the only vendor selling such things. We will see more
products that magically can identify "bad things" in TLS traffic by
applying everything from AI to Blockchain.
We will almost certainly see a whole new generation of devices doing
weirdness with TLS and who will drop or manipulate packages that contain
things they don't know (like... a version negotiation field with TLS
1.4 or a large post quantum key exchange message).

The question I want to ask: What can we do *now* to stop this from
happening when TLS 1.4 will be deployed? I have the feeling GREASE
won't be enough...

Hanno Böck

mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42