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

"Salz, Rich" <rsalz@akamai.com> Thu, 26 September 2019 13:03 UTC

Return-Path: <rsalz@akamai.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 394DE12002F; Thu, 26 Sep 2019 06:03:02 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 jQMrpvvS0a-r; Thu, 26 Sep 2019 06:03:00 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A510F12011D; Thu, 26 Sep 2019 06:03:00 -0700 (PDT)
Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8QCvtCT003229; Thu, 26 Sep 2019 14:02:40 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=+kRdfeIquDcMJbG1l6aIeaJ40NPPCoutthKuFcG02CE=; b=BV+Xo/68xeWPe8HjHsGw/6UTSXL4aMDgaA9Rqz2i7OZDAAnDTR3/ll4k/pZOf2rVr2Vu nfJK4A2nfouynoqB9JIU9oXEIdQTnRKQFVVcoWhHKZ2OhW3+4sm5o8Dk+8KiawHL3Dm5 w3X4gu4seVf4SLcHLmHD5tWgOZ/l+sIV7qtLyi9lGZ9sjSv5TeOjaRJp5qa1GT7sxCxY S6gI1CFe1NRFaQuKQJA7SlhciGIJVMvlzdfMqiiQRFuroJNekpm2bQH3AHv8R+j1Dj5H emxYXPaoRiMj5wwqPLgj91YSSHD3/z725Bn3MkooUAFHhgfwsAiqfOioTiKPLSPBAHIr RA==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2v73q9m9j1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 26 Sep 2019 14:02:39 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8QD2JhD012567; Thu, 26 Sep 2019 09:02:38 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint1.akamai.com with ESMTP id 2v73vpx57e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 26 Sep 2019 09:02:38 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 26 Sep 2019 09:02:37 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Thu, 26 Sep 2019 09:02:37 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, "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+oSGSF7Gj3Q==
Date: Thu, 26 Sep 2019 13:02:36 +0000
Message-ID: <BF5F63A6-105B-47C6-8B65-29A290A16E76@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.32.137]
Content-Type: text/plain; charset="utf-8"
Content-ID: <6B87407B955D4F468E876499D8E4F91F@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-26_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909260122
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-09-26_06:2019-09-25,2019-09-26 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 priorityscore=1501 impostorscore=0 suspectscore=0 adultscore=0 malwarescore=0 lowpriorityscore=0 clxscore=1011 bulkscore=0 mlxlogscore=999 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909260122
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XsDxzmW-rNmiWO6T2abOExOXQxs>
Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation
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: Thu, 26 Sep 2019 13:03:02 -0000

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 :)

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