Re: [saag] [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

<hannes.tschofenig@gmx.net> Tue, 01 October 2019 13:37 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9031200CE; Tue, 1 Oct 2019 06:37:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 HiKBuu4NXKeP; Tue, 1 Oct 2019 06:37:57 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E87120024; Tue, 1 Oct 2019 06:37:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1569937065; bh=5hPbXsq/aYiq0TmayXlY/PFDCT8a/arWi74oPfr0YhU=; h=X-UI-Sender-Class:From:To:References:In-Reply-To:Subject:Date; b=j9pQ2UTDzNK9AQ+hZMiLqbd+WirvwsQdREZqc2de9/cTsX49Hq5jFQIsMDZ9Xe1Hp gZ/Ilv7y9PfoaUxf2kCxPsHJeFzkvJ6Gb9GjL+zem+MZIn3oeg4cBOSPODa3E2HKZo kUrm6k0me9FX1wHHerh05gx6X5so64JOqAqowN6k=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from E108678 ([80.92.116.217]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M1po0-1iHVGj38X2-002If7; Tue, 01 Oct 2019 15:37:45 +0200
From: <hannes.tschofenig@gmx.net>
To: "'John Mattsson'" <john.mattsson=40ericsson.com@dmarc.ietf.org>, <TLS@ietf.org>, <saag@ietf.org>
References: <03B5BDAC-5B17-47B2-85D0-225DCCABDC42@ericsson.com>
In-Reply-To: <03B5BDAC-5B17-47B2-85D0-225DCCABDC42@ericsson.com>
Date: Tue, 1 Oct 2019 15:37:05 +0200
Message-ID: <024b01d5785d$51b3d7d0$f51b8770$@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQDADKbUP4/3gAM9SAzHCUgPUKIoKalwn67A
Content-Language: de
X-CheckRecipientChecked: true
x-ts-tracking-id: 71b26417-e9f7-43f0-aea7-971ab7e956ae.1
X-Provags-ID: V03:K1:YXavmIPscQmXVHU8cmwy3sUoUbpf9/cFySyAMVFVFBnjxboMUIx SkSPV0IxG37EEUz0GVDmyj7ah4V56XgFSeN+/++jU5sqHMubYvLpqhYIiG09KYav+cH6hXf wSVkwkhsT2qVDxRnophyyU1l4s3zEHbkYEJTX0qUAueYua08E4k2PDQfBMZ3zZaCVxAT5R9 /+kbpeV4juqZYTFdPHc+A==
X-UI-Out-Filterresults: notjunk:1;V03:K0:y1H40qmI3A0=:EqIKCepVNvv6OzOnSGE+mA FGJajWba3bm8CH05fDlQhY5W7KSG+50tDiFnUvgkTWOqYku5U9wU2ha/VV/fMk+Sc4CnpT9vz 4bJamvify3N6/CDmly2eBMlr8mB+5vDvBh9fQjtsoEXd4tQjHR8z+/7/AXofxwxEdN3KknAkP qnI0JncnXb2EH3tsh6pLDMUBCFZGhovl5QAoYn5RyT4AaWgpAfAifEmiIzW/MQo1heox3+9fj fT5lZb4xru2E3rxdrlxCOZ8c3lKjB2V+p/RGZclasBjQJcd24wybiMSTRk2sxUiaadrBJLdqz hQIfiNJybO7NJnq+rH+YWeE7z1eMLgKjDBnLei3BmG4wC3Opajttz+IXV9thH1QKlzXHmZVnP wRIf8g+rkmojoed1E7i3Bmd3Qf/EgbVqq2gm1v6DvSunZ0XfFccVErAKU7G8S9BMD/v0Y2bQv LtAC2bzQ4S+F6EzAvufQ2wJk9j6mh7he459HXhQaAhbxtDvwI2MkfiboqqpknoodOLZBBPISb cCCvVi/bv+1ZONk3uUuSvfN8fYusQYIkX4yaEC3kCtAIPwPhyM8cJEmYs9t6hAf6zQvUdFcp5 rty11QNNQQ/I9WOVgURoN/6KA9gS1vVXWiu3nWb/c8euNZ2vNdb3JrbRhZ6hYU/scaR9dfbOs FTgERN3i+kNcTxqjL5vrc4CHHswfF6j0u6e7skA0pJjgi2dqPbKWGGWHUZbXxrFsMOsq66tp3 DETn0wNvJBG7YSkMchmlhN8SKQCSiWGEs9M3rNWGQr1Y2Gh4SRDf3ZYfyLqHZnxN4MDe6IoAH 3GIvi4+1Ft3Fal4NrRHnSLVGuaLjAYg7gCL31F/hd8mc15vxvs7ng8lGANUeWOkW9VhwTcyc2 eUcr0NBEZrVjyXhMTNXK0aNsBMY7Q6T1TJp70rUkcCVAECqu0mvKF5zxhvBJbzHoaBOv2icgz 8T3PibTW2sCyI3H6EfORrHA2L5gAACY/Uqdk33K6xfSCnf834JW0qRapgi4tuCDQE+hPiFlZp WjaJLROix/ShNVr9UdUYSJKLPPmPWeQW7fkoGQSvAnkGcY2O38fprvyjixsLN6H6qiKQOpjyJ z0ErSg5u73pubICmbBEOi4nqzzSX4nPiIbCtxpEYDds09T9cyRrSJtPAMBeUvrHrL0+kNcHsd 1uiF9quTIZgzbv2qKB1jBhQeQmxQDbKA4FmuFkfuexdgDpaBm274Y5kSY4iMnU8rFzLv64fj7 2XZ1Fsc08wu3s2ieyMBXrfc7GGqhTLFpbdGS83ee5IFAmrI0A23tXvV9Y7sM=
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/_IIl4HynOSA-t1v-Q8Uy8lWAq_A>
Subject: Re: [saag] [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Oct 2019 13:37:59 -0000

IMHO the problem with deprecation is not in the IETF but rather with the deployments. 

Ciao
Hannes

PS: As Kathleen noted TLS 1.2 and DTLS 1.2 are perfectly fine if you follow RFC 7925/7525.

-----Original Message-----
From: TLS <tls-bounces@ietf.org>; On Behalf Of John Mattsson
Sent: Donnerstag, 26. September 2019 14:18
To: TLS@ietf.org; saag@ietf.org
Subject: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

Hi,

Hopefully, we have learned some lessons from the TLS 1.0 and TLS 1.1 deprecation. TLS 1.0 and TLS 1.1 are (to cite Martin Thomson) broken in a myriad subtle ways and should according to me optimally have been deprecated years ago.

3GPP mandated support of TLS 1.2 in Rel-13 (2015) but could at that time not forbid use of TLS 1.1 as that would potentially break interoperability with some Rel-12 nodes (that had TLS 1.2 as should support). The lesson 3GPP learned from this was the need to as early as possible mandate support of new protocol versions. With TLS 1.3, 3GPP took action early and TLS 1.3 support was mandated for network nodes in Rel-15 (2018) and for mobile phones in Rel-16 (2019).

At some point in time we will want to deprecate TLS 1.2. To enable that, TLS 1.3 support should be mandated or encouraged as much as possible. I would like to avoid a situation where we want to deprecate TLS 1.2 but realize that it cannot be done because some implementations only support TLS 1.2. How can IETF enable smoother and faster deprecations in the future? The browser industry has a decent track record of algorithm deprecation and I hope to soon see the following warning in my browser:

“TLS 1.2 is obsolete. Enable TLS 1.3 or later.”

Other industries have less stellar track records of algorithm deprecation.

How can IETF be more pro-active regarding deprecations in the future? In the best of words, nobody should be surprised when IETF deprecates a protocol version or algorithm. NIST and similar organizations in other countries have the practice to long time in advance publish deadlines for security levels, algorithms, and protocol versions. Can the IETF do something similar, not just for TLS but in general? For TLS, there are several things to deprecate, in addition to MD5 and SHA-1, also PKCS1-v1_5, RSA-2048, 224-bit ECC, ffdhe2048, and non-recommended cipher suites (Static RSA, CBC, DH, NULL, etc.) should be deprecated in the future.

Cheers,
John

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls