Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation
Daniel Migault <daniel.migault@ericsson.com> Thu, 26 September 2019 13:51 UTC
Return-Path: <mglt.ietf@gmail.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 476E41208B3; Thu, 26 Sep 2019 06:51:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 n7gZf3JQGG69; Thu, 26 Sep 2019 06:51:09 -0700 (PDT)
Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com [209.85.222.47]) (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 A73E1120839; Thu, 26 Sep 2019 06:51:09 -0700 (PDT)
Received: by mail-ua1-f47.google.com with SMTP id n2so778488ual.11; Thu, 26 Sep 2019 06:51:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=L673KrqYV3m85ireH46XDqxBxJGIHlq1NScojDcAKTE=; b=Z14uDSEflqVdo7oigeqDn035H3xr+VG4GdJO1Xt6CeK76UvlozBIb97JJoU7141fRu 9iTQ1VoVn/DUnmwFC3MgGPu+2Woao/9mrFWh8ivnTnEy7hHevuiC9NJiJvwYGfdSiqDT Cywi0ETKozCDbGs67rCze8hbppAyMSPC12rllgvg17AEKE+2hbIr38sf54/HbjYNjUhD IcxBQUi0lM6Z+I2Ro8QOzHnWU0mE2PnTgvuHKR6ByOQbA2ZIEBtya2jaohFlHU3RkGx+ DksX7rlvaIJo9N34bgOUh46PsCrYyv99FvJ2b9Xatd8zi/B73ky+EwBhhDnEbwToC3jO 5wVA==
X-Gm-Message-State: APjAAAWd41beGOvrKa05vjnjr/v0A1MoWylvHMsSMlgFwmcqLquADk9y DLJe6Sf0Ka9AciqafMGcP3ah0sXPMImXnFtgoXFISg==
X-Google-Smtp-Source: APXvYqwyH/0e1PkHgReWGdlZS8TlpiTjUemlpXH0RWBUamJwgYjAAe3SnSrhXLUW/K3pV5EE4Zt/ImFT2VQlYBflClg=
X-Received: by 2002:ab0:6897:: with SMTP id t23mr1737156uar.88.1569505868644; Thu, 26 Sep 2019 06:51:08 -0700 (PDT)
MIME-Version: 1.0
References: <03B5BDAC-5B17-47B2-85D0-225DCCABDC42@ericsson.com>
In-Reply-To: <03B5BDAC-5B17-47B2-85D0-225DCCABDC42@ericsson.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Thu, 26 Sep 2019 09:50:57 -0400
Message-ID: <CADZyTkk-6CST3ExXsNb=35+t+SH9igaNuN9ToehES5sqTxAUsQ@mail.gmail.com>
To: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>
Cc: "TLS@ietf.org" <TLS@ietf.org>, "saag@ietf.org" <saag@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c604e80593750ff1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/0abNJm0q71EpvGC3CJVKtDBFVbs>
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:51:22 -0000
Thanks for raising this discussion John, we have been struggling with this in curdle as well and ipsecme. This is also a topic that I believe would be useful to improve the security. One aspect is that some implementers go to the IANA pages and believe that everything on the pages is acceptable. I believe that it would be worth adding some status associated to the code points. Currently, in most cases a reference is associated to the code point. In some cases, the reference is the RFC or document creating that created the code point in other cases, the reference could be the RFC that deprecates the code point. There is no specific rules, and that is probably something that would worth being clarified. That being clarified, I still believe that it could be useful to have a some sort of indication like a column that indicates whether the code point is deprecated or not. This may involve additional terminology depending on the level of information needed. Another aspect would be to have software automatically checking which are the code points status. This would of course only solve one side of the problem as a device may end up on becoming silent, but that is probably what should occur to non maintained devices. Yours, Daniel On Thu, Sep 26, 2019 at 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] Lessons learned from TLS 1.0 and TLS 1.1 de… John Mattsson
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… Salz, Rich
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… Kathleen Moriarty
- Re: [TLS] [saag] Lessons learned from TLS 1.0 and… Michael Richardson
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… Daniel Migault
- Re: [TLS] [saag] Lessons learned from TLS 1.0 and… Daniel Migault
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… Martin Thomson
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… Stephen Farrell
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… Daniel Migault
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… Martin Thomson
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… Stephen Farrell
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… Daniel Migault
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… Simon Bernard
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… Salz, Rich
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… Eric Rescorla
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… Salz, Rich
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… David Benjamin
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… Benjamin Kaduk
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… Stephen Farrell
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… Daniel Migault
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… John Mattsson
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… John Mattsson
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… Kathleen Moriarty
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… Kathleen Moriarty
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… hannes.tschofenig
- Re: [TLS] [saag] Lessons learned from TLS 1.0 and… Michael Richardson
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… Daniel Migault
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… Peter Gutmann
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… John Mattsson
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… Christopher Wood
- Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.… Hannes Tschofenig