Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 20 October 2017 18:27 UTC

Return-Path: <ilariliusvaara@welho.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 D242C134308 for <tls@ietfa.amsl.com>; Fri, 20 Oct 2017 11:27:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 wM87nG3dOh6K for <tls@ietfa.amsl.com>; Fri, 20 Oct 2017 11:27:35 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFAF31329B5 for <tls@ietf.org>; Fri, 20 Oct 2017 11:27:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 7473DB5208; Fri, 20 Oct 2017 21:27:32 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id OSS1EjeXlD-3; Fri, 20 Oct 2017 21:27:32 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 5A3EC2318; Fri, 20 Oct 2017 21:27:26 +0300 (EEST)
Date: Fri, 20 Oct 2017 21:27:25 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "Ackermann, Michael" <MAckermann@bcbsm.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "Salz, Rich" <rsalz@akamai.com>, Darin Pettis <dpp.edco@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20171020182725.7gim6dg3mrl67cuh@LK-Perkele-VII>
References: <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <c1c0d010293c449481f8751c3b85d6ae@venafi.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <E84889BB-08B3-4A3A-AE3A-687874B16440@akamai.com> <CAPBBiVQvtQbD4j3ofpCmG63MEyRWF15VL90NOTjeNqUOiyo6xg@mail.gmail.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <CY4PR14MB1368CBA562220D9A3604F0FFD7430@CY4PR14MB1368.namprd14.prod.outlook.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <CY4PR14MB136835A3306DEEFCA89D3C2DD7430@CY4PR14MB1368.namprd14.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CY4PR14MB136835A3306DEEFCA89D3C2DD7430@CY4PR14MB1368.namprd14.prod.outlook.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/06GIdbZuzaT3bO8oiW7frGxZ58E>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
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, 20 Oct 2017 18:27:37 -0000

On Fri, Oct 20, 2017 at 04:41:04PM +0000, Ackermann, Michael wrote:
> So it sounds like we are in agreement that continuing to use TLS 1.2
> is not a viable long term  alternative.  

If one looks at long time horizon...


TLS 1.2 will very probably remain viable until quantum computers come
and demolish its security, unfortunately.

Yes, quantum computers will demolish TLS 1.3 as it is currently, but
adding PQC into 1.3 is much easier than adding it into 1.2. With TLS
1.3, the biggest problems is choosing the PQC algorithm, not
integrating it, whereas TLS 1.2 requires would require very nontrivial
integration work too.

Oh, and come quantum computers, you will find that PQC schemes are much
less well-behaved than the pre-quantum schemes in use. Thus many tricks
that worked no longer work. So you would be better just adapting,
because come QC, you don't have choice but to, potentially very
quickly.

Also, with regards to support, I would be much more concerned about
software dropping support of, or regulations mandating disabling of,
RSA key exchange than TLS 1.2 as whole. There are already TLS libraries
that lack RSA key exchange, despite the fact it is MTI. Furthermore,
that sort of thing is much more feasible on server side, as client
support for ECDH (or at least DH-2k) is just about universal.


-Ilari