Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

mrex@sap.com (Martin Rex) Tue, 30 April 2019 23:49 UTC

Return-Path: <mrex@sap.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 BA8DE1203E8 for <tls@ietfa.amsl.com>; Tue, 30 Apr 2019 16:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 QNmw1LTWvwcE for <tls@ietfa.amsl.com>; Tue, 30 Apr 2019 16:49:54 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27661200D8 for <tls@ietf.org>; Tue, 30 Apr 2019 16:49:54 -0700 (PDT)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 44tytm3vmjzyPL; Wed, 1 May 2019 01:49:52 +0200 (CEST)
X-purgate-ID: 152705::1556668192-00000214-3368DD79/0/0
X-purgate-size: 738
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail07.wdf.sap.corp (Postfix) with ESMTPS id 44tytm1Tz8zGpC5; Wed, 1 May 2019 01:49:52 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 21F5C404C; Wed, 1 May 2019 01:49:52 +0200 (CEST)
In-Reply-To: <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com>
References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <2EF7433E-DB94-497F-80D7-2A060097261B@dukhovni.org> <CADZyTkkJ63uq-Uukp00XAn+vFs6JtsNXF7stK=wbJpOvNBSs9g@mail.gmail.com> <5C3C015B-88B9-4502-861B-C59120B2F151@akamai.com> <D08B793B-3FE2-48A1-8ADD-C55C47300683@dukhovni.org> <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com>
To: Martin Thomson <mt@lowentropy.net>
Date: Wed, 1 May 2019 01:49:52 +0200 (CEST)
CC: tls@ietf.org
Reply-To: mrex@sap.com
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20190430234952.21F5C404C@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/h4dS6QZV7MI8edNOIUVl0VH_7mw>
Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 30 Apr 2019 23:49:57 -0000

Martin Thomson <mt@lowentropy.net> wrote:
> On Sat, Apr 27, 2019, at 07:29, Viktor Dukhovni wrote:
>> The sound-bite version is: first raise the ceiling, *then* the floor.
> 
> Yep.  We've done the ceiling bit twice now.
> Once in 2008 when we published TLS 1.2 and then in 2018
> with the publication of TLS 1.3.  I'd say we're overdue for the floor bit.

Just that this rationale is a blatant lie.

It is formally provable that from the three protocol versions:

 TLSv1.0, TLSv1.1, TLSv1.2

the weakest one is TLSv1.2, because of the royally stupid downgrade
in the strength of digitally signed.


Disabling TLSv1.0 will only result in lots of interop failures
and pain, but no improvement in security.


-Martin