IETF Logo Mail Archive

Re: [TLS] The future devices that will break TLS 1.4

Hubert Kario <hkario@redhat.com> Mon, 15 January 2018 12:37 UTC

Return-Path: <hkario@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4EF1275C5 for <tls@ietfa.amsl.com>; Mon, 15 Jan 2018 04:37:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXh8n8nTcfNH for <tls@ietfa.amsl.com>; Mon, 15 Jan 2018 04:37:28 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A081126E3A for <tls@ietf.org>; Mon, 15 Jan 2018 04:37:28 -0800 (PST)
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E8064883C4; Mon, 15 Jan 2018 12:37:27 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (ovpn-200-22.brq.redhat.com [10.40.200.22]) by smtp.corp.redhat.com (Postfix) with ESMTP id 19DAA5D6A6; Mon, 15 Jan 2018 12:37:26 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Mon, 15 Jan 2018 13:37:20 +0100
Message-ID: <1831387.ULqcxPagE8@pintsize.usersys.redhat.com>
In-Reply-To: <249425c3-780f-5850-366b-9d87d3b31af4@huitema.net>
References: <20180113000206.6bc36af6@pc1> <57CA48F7-CC49-42A3-AF9B-BCB4778264B2@gmail.com> <249425c3-780f-5850-366b-9d87d3b31af4@huitema.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1567765.pWrhdgLdZ2"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 15 Jan 2018 12:37:27 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/043ORer3_u4i9njCLZ82nfnFOiU>
Subject: Re: [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: Mon, 15 Jan 2018 12:37:29 -0000

On Saturday, 13 January 2018 03:31:23 CET Christian Huitema wrote:
> On 1/12/2018 1:53 PM, Dan Wing wrote:
> > 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...
> 
> Data sets. Machine learning algorithms are trained with data sets. If we
> produce reference data sets showing what TLS 1.4 looks like, the vendors
> can retrain their AI and start recognizing the new version for what it
> is, rather than some unknown attack.

doesn't help with already deployed gear, and we really can't predict how TLS 
1.4 will look like to give examples of it to them right now
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

v2.23.0 | Report a Bug | By Email