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

John Mattsson <john.mattsson@ericsson.com> Tue, 01 October 2019 07:58 UTC

Return-Path: <john.mattsson@ericsson.com>
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 90DCA1200FB; Tue, 1 Oct 2019 00:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 uOKQ06_H3sdD; Tue, 1 Oct 2019 00:58:05 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50077.outbound.protection.outlook.com [40.107.5.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 206481200FE; Tue, 1 Oct 2019 00:58:04 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q4WAkZvf5T0HUJfB9tSwH6lfWFuyM4FM3rXot6fXd3aekU1jEdI3EEeLRAYPwVeA910r8iZy6kQUuio5zvuGt4dTTPwDawOxZws5yAY4DgeLUfJrqaJBtw5+sNWS4jtMSmrEcSLTa3m9i4dQJZV2OyK9CSluu9UoLfg3ye7bJtCtpZaH0bgaQrcixiNfwmKwaENwf5JQJQJL8LM3WW/M15BrArLb5rtlllPoHcPQVFmCUEVEBw0ddlJo3D0XdV/j2fUJypWUi9IpZewb+IYa5jGFfKSBoR6eJ0XDRs8MY5ldg8CYtw5eUG8YqeVnxHpTGPZcMvrRQjqKqKdHblmHgg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zkXciIVR0FP6L+X/GXVrquNICC9dYPh1b3+6tbJ0oaM=; b=Edpt0noizwqjayXaocdwqCl9o8F+abowL1T/97cgD5w6tCvl1tvgaFtQ+DXZz6OTIyOrXn298FX1gxDzI7piAElJ6TMEQvNzUgK3Sufkkap3J78sXW8xAZHxb+fHlMmcvKC6T5FQKMMCTbPeDyX7kZVm7pX8NZ1qK7CWb5mF8HN/DYyGJDP9oqwT7BJjtKBlN0Y+30eB+yj8ttpto1MUWB/JChdb94ryHIu9jPFE/GiI53IratrgPTFG3qlS3da79P9aOdsEBgCOp/x92y0nvI1mfqkAf346gZKYfxiHBVUZs5mR6P242O/gEa/U/9Rc7zbF7kKTkm09FPWSJ26dXw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zkXciIVR0FP6L+X/GXVrquNICC9dYPh1b3+6tbJ0oaM=; b=mq+oXqSfjMe6DQQ9yTOnje9Yyx10aRw5j4OFPCa58xwnYjDK/0d7K0eRBWnHNSmdXz02zgicrqbkh/UzheGJsDjjuf8Tgw6saAdtCx8j2nNExFoVne2uDV9EXReO5mh5VGaYUxCcLa72Rwv2F561MRfxtO/wPSvG0OJ9zJzSKJM=
Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB3148.eurprd07.prod.outlook.com (10.170.247.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.9; Tue, 1 Oct 2019 07:58:02 +0000
Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2305.017; Tue, 1 Oct 2019 07:58:02 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, "Salz, Rich" <rsalz@akamai.com>
CC: "TLS@ietf.org" <TLS@ietf.org>, "saag@ietf.org" <saag@ietf.org>
Thread-Topic: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation
Thread-Index: AQHVdGqrOKnGYrSipku+oSGSF7Gj3ac9+dkAgAeauwA=
Date: Tue, 1 Oct 2019 07:58:01 +0000
Message-ID: <F1D7BC9F-0CC7-459C-A338-DD54F5513EF3@ericsson.com>
References: <BF5F63A6-105B-47C6-8B65-29A290A16E76@akamai.com> <8B2B78CF-F312-4F7A-8EB1-A712F309A754@gmail.com>
In-Reply-To: <8B2B78CF-F312-4F7A-8EB1-A712F309A754@gmail.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1d.0.190908
authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com;
x-originating-ip: [192.176.1.84]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8d8f73d1-4d64-4c00-d112-08d746451549
x-ms-traffictypediagnostic: HE1PR07MB3148:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <HE1PR07MB3148EEEDDE9C3FA5E7042BFD899D0@HE1PR07MB3148.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0177904E6B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(396003)(376002)(346002)(366004)(39860400002)(136003)(199004)(189003)(51444003)(13464003)(71190400001)(26005)(316002)(99286004)(966005)(33656002)(6436002)(229853002)(478600001)(76176011)(5660300002)(256004)(25786009)(14444005)(14454004)(71200400001)(86362001)(6486002)(44832011)(486006)(476003)(8936002)(64756008)(102836004)(2616005)(76116006)(66066001)(54906003)(6116002)(446003)(6246003)(11346002)(110136005)(53546011)(6506007)(305945005)(7736002)(66946007)(58126008)(66574012)(66556008)(4326008)(186003)(6512007)(2906002)(81156014)(81166006)(6306002)(8676002)(36756003)(3846002)(66476007)(66446008)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3148; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Bg0Q5ow2Twoka25D7eEpNCm/+arujI6ODo7GG3rz5urmA7kdFK/iVwaH0bGd7zf6aJ9zNWSU1xjZVU9G89SW1vbfALQdSZYzrz0wXLYvQ1NtR3LuQ9I8ugd0CIPE3mm5/RFkBZKhC2khOxv0z2V9ohXXQiSY4rzYcFzpmx79j/nYFHQR+7rlsWJwOznQ5TOORHGfp6aknVNNRx8WeXzhQT7rwO43q8ecWt19ueJwdH+Xvnk0DU+tZhliHVCO8D8C38MGuEI11Zbcwl08q+5+NLKaSldRMZcQa4EcDdkF/MxqZ3TcSNEdD4/hhOs5ctYdZgm9UsqqJrsmHqaCRkUhV9VjrqRGiQtVISYWCuTTuNE2blOv1LeJRH9Rwkjy5+C1ta6jY49MrziEMfvHYjgGa2P2rCUwy+FNEEEDgIYWWXXT+eF1z4kEzGRilA40HAxTwTEHJGUVwtIvM7HFDtF6tA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <680BB3D61A9F014187F8E81463EAD89D@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8d8f73d1-4d64-4c00-d112-08d746451549
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2019 07:58:01.8152 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: iokg4aoxuc40s2fZLE9OhnixQ1bSiujPc8b7NUaAmWyvCwF2wmzaos+cjWfgMRgkSjlZzaR/pbk19rE7ASDSlzNtTRXp1IigcSBohOQyM7o=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3148
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/QAJEP0CUr3gPvfpl1tBElriiJhc>
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 07:58:09 -0000

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>; wrote:

>NIST has pushed back their date for US government organizations to have a plan to support TLSv1.3, what’s the driver to get ahead of that?

NIST SP 800-52 rev 2 requires support for TLS 1.3 by January 1, 2024. I think that is a good and ambitious plan. In fact it would be very good if IETF agreed on the same requirement.

> I think encouraging implementation of TLSv1.3 is good and important, but are there other ways besides deprecation?

Yes, I think there is at least two things IETF can do:

- The first thing is to do like NIST and already now give implementors a date when support for TLS 1.3 is required.

- The second thing is to do like 3GPP and mandate support for TLS 1.3 in new implementations and deployments.

This would avoid two thing that happened in the past. First, IETF published RFC 8261 that mandated support for DTLS 1.0 and not DTLS 1.2 almost 6 years after RFC 6347 made DTLS 1.0 obsolete. Secondly, just 7 months after publishing a draft relying on DTLS 1.0, IETF started working on a draft forbidding it’s use.

Cheers,
John

-----Original Message-----
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>;
Date: Thursday, 26 September 2019 at 15:50
To: "Salz, Rich" <rsalz@akamai.com>;
Cc: John Mattsson <john.mattsson@ericsson.com>;, "TLS@ietf.org"; <TLS@ietf.org>;, "saag@ietf.org"; <saag@ietf.org>;
Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

    
    
    Sent from my mobile device
    
    > On Sep 26, 2019, at 9:02 AM, Salz, Rich <rsalz@akamai.com>; wrote:
    > 
    > These are excellent points.  Perhaps they can be squeezed into https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/  ?  It's been waiting 90 days, a brief reset might not hurt :)
    > 
    This would not be a brief reset and I’d prefer not to see them combined into the existing draft with WG agreement.
    
    With RFC7525, TLSv1.2 can be configured to be secure.  I see the points made, but don’t see the urgency as obsolete is different from depreciation.
    
    I think encouraging implementation of TLSv1.3 is good and important, but are there other ways besides deprecation?
    
    NIST has pushed back their date for US government organizations to have a plan to support TLSv1.3, what’s the driver to get ahead of that?
    
    A vulnerability would speed things up, but I do hope that does not happen.
    
    Best regards,
    Kathleen 
    
    > On 9/26/19, 8:18 AM, "John Mattsson" <john.mattsson=40ericsson.com@dmarc.ietf.org>; wrote:
    > 
    >    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
    > 
    > 
    > _______________________________________________
    > TLS mailing list
    > TLS@ietf.org
    > https://www.ietf.org/mailman/listinfo/tls