Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation
Daniel Migault <daniel.migault@ericsson.com> Tue, 01 October 2019 20:37 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 DD67E1200C1 for <tls@ietfa.amsl.com>; Tue, 1 Oct 2019 13:37:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.477
X-Spam-Level:
X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 7ftYqtrtyrOZ for <tls@ietfa.amsl.com>; Tue, 1 Oct 2019 13:37:26 -0700 (PDT)
Received: from mail-vk1-f179.google.com (mail-vk1-f179.google.com [209.85.221.179]) (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 0B37F12007A for <tls@ietf.org>; Tue, 1 Oct 2019 13:37:26 -0700 (PDT)
Received: by mail-vk1-f179.google.com with SMTP id p189so3827342vkf.10 for <tls@ietf.org>; Tue, 01 Oct 2019 13:37:25 -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=LkOH6CJVQUumqCy5uidq36gshbww8/4bR/jkL36xEbQ=; b=RS2+wjdv1UEMrN0d0mjLfMk5IbxF33vrgBgPWSQsjieypOvmpEJReVuiTv2CqeiPwm zylfq5QWvjnvULWyt7ftPTW21ZBeeP6W9nP8jQLd94fLzbyLjyz1XpIjjtLnE4i67+xi 2yrAVjsBnt/LVHamSRD4Hinx8scp3m0z/d2dmhW1P5/oc+0HgJelG2T/7KVCEavWf0Zu 0NOzmQpXNWH7kNasCR7gnJaU3ennpF2pEbz3Hn50kdGcEENJrtudMXecShQ8IXQHvPz9 yA8mHx6k34Uh35Oqm0yeA+0qKqJgoCJaAf7ljwwU3kUnQqBCmDx1sCopPPkp2qUQ1hIn HIxA==
X-Gm-Message-State: APjAAAXEq/VD6+LM3v83bacikE+mvrL6M0q9zknLNY2HlDV/KB1iArRC N4cwFYDmDIGe2nW5VmLfnYoR2Gl4bIJBgyzUKc8=
X-Google-Smtp-Source: APXvYqwcAU18L6slwJrxnTo+4/fwNZFlYT3k9AeVJ0uFwoyK/aXed3J12eqXNFFJ1X/eNMmMd4MhceQjjQN2feuwJ0A=
X-Received: by 2002:a1f:d8c4:: with SMTP id p187mr165476vkg.47.1569962244993; Tue, 01 Oct 2019 13:37:24 -0700 (PDT)
MIME-Version: 1.0
References: <BF5F63A6-105B-47C6-8B65-29A290A16E76@akamai.com> <8B2B78CF-F312-4F7A-8EB1-A712F309A754@gmail.com> <CADZyTknH0ivQc-xW-di1XKC7w-9A5TCF8vhLLCrR9jQbcqY5dw@mail.gmail.com> <d4b01c69-6047-467b-8538-9780f6872fe1@www.fastmail.com> <4DE775B5-B15B-469F-A50C-3DB5B86AA5D4@ericsson.com> <CAHbuEH5FtCDe55eoXtbcSxNAg0Vc0-NUXDDBKgKUcJQQosUXxQ@mail.gmail.com>
In-Reply-To: <CAHbuEH5FtCDe55eoXtbcSxNAg0Vc0-NUXDDBKgKUcJQQosUXxQ@mail.gmail.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Tue, 01 Oct 2019 16:37:13 -0400
Message-ID: <CADZyTkmMfr4+wNmW929d30GeM+5oFfh0wJEX8R_n9-v5pWx5tw@mail.gmail.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Cc: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ec84c30593df512e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/lzShHiXGZvHFF4qNqCRt32f1Mr4>
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: Tue, 01 Oct 2019 20:37:28 -0000
Hi Kathleen, On Tue, Oct 1, 2019 at 7:07 AM Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > > > On Tue, Oct 1, 2019 at 4:00 AM John Mattsson <john.mattsson= > 40ericsson.com@dmarc.ietf.org> wrote: > >> Martin Thomson <mt@lowentropy.net>; wrote: >> >> >When we release a new version of something, we are sending a message: >> > >> >1. new implementations and deployments MUST include support for newer >> versions >> >2. existing implementations and deployments SHOULD be updated to support >> newer versions >> >> I agree very much with this summary and I would like to have it published >> somewhere. Take for example RFC 8261. It was published almost 6 years after >> RFC 6347 made DTLS 1.0 obsolete and still mandated support for DTLS 1.0 and >> not DTLS 1.2. I think this is one of the lessons IETF should learn from the >> TLS 1.0 and TLS 1.1 deprecation. How do we stop this from happening in the >> future? For an external viewer it must look pretty strange that IETF in Nov >> 2017 published an RFC relying on DTLS 1.0 and then 7 months later started >> working on a draft forbidding its use.... >> >> I would like to see something like the following statements published: >> >> "New implementations and deployments MUST include support for TLS 1.3" >> > We have this already, I believe in new drafts. > The current wording does not, in my opinion, make the message clear in the current draft. Maybe that is a perception of non native English speaker, but there are probably three sentences that could in my opinion make the message clearer. > > >> "Existing implementations and deployments SHOULD be updated to support >> TLS 1.3" >> "Existing implementations and deployments SHALL support TLS 1.3 by >> January 1, 2024" >> > > Are you proposing a draft to state this? If agreeable, this could be a > quick draft and support for 1.3 is a reasonable request to align with > requirements in industry. I'm not sure if our statement will drive the > date as much as NIST's, but it couldn't hurt and I would be surprised if > there were any objections to this. > > I don't think anything other than an RFC is the right approach, unless > there is an avenue I am not thinking about as having IETF consensus would > be what you'd want for it. > > >> >> >> """The expectation is that TLSv1.2 will continue to be used for many >> >> years alongside TLSv1.3.""" >> > >> >Some people have that expectation, but I think that John is right to >> challenge it. >There remain reasons that people are sticking with 1.2 for >> now, but those reasons >are mostly to do with allowing time to flush out >> the vestiges of a dependency on >some of the TLS 1.2 idiosyncrasies. >> >> I agree with Martin, and irrespectively of whether it is true or not, I >> do not see any need to have this sentence in an IETF draft. >> > > As for this sentence, we'll see where the discussion settles out - > removing or altering it. > > Best regards, > Kathleen > >> >> Cheers, >> John >> >> -----Original Message----- >> From: TLS <tls-bounces@ietf.org> on behalf of Martin Thomson < >> mt@lowentropy.net> >> Date: Friday, 27 September 2019 at 02:03 >> To: "TLS@ietf.org" <tls@ietf.org> >> Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation >> >> So I agree with Kathleen's conclusion: not to change the goals of the >> current document. But there are changes that I think are necessary (and >> thanks to Daniel and John for highlighting these). >> >> BTW, I've moved this to the TLS working group, because this is an >> active topic there and I don't see anything in my email that SAAG needs to >> concern itself with. >> >> On Fri, Sep 27, 2019, at 01:00, Daniel Migault wrote: >> > My understanding of deprecating of TLS1.0 TLS 1.1 is that: >> > a) new software do not use these versions >> > b) existing software stop supporting these versions. >> >> That differs from my perspective. >> >> When we release a new version of something, we are sending a message: >> >> 1. new implementations and deployments MUST include support for newer >> versions >> 2. existing implementations and deployments SHOULD be updated to >> support newer versions >> >> When we deprecate an old version of something, we are sending a >> message: >> >> 3. only use this old version if you absolutely have to >> 4. you are encouraged to take active measures to remove the need to >> use the old version >> 5. you have our support if you decide not to support this old version >> >> Now, "support" from the IETF is about as meaningful as you think it >> is. And you can s/MUST/really ought to/ and s/SHOULD/may wish to/ >> [RFC6919]. >> >> In browser-land, we've decided to form a coalition when it comes to >> removing TLS 1.0/1.1. 3GPP have obviously got their own support group, >> which seems to be functioning effectively, which is great. >> >> > """The expectation is that TLSv1.2 will continue to be used for >> many >> > years alongside TLSv1.3.""" >> >> Some people have that expectation, but I think that John is right to >> challenge it. There remain reasons that people are sticking with 1.2 for >> now, but those reasons are mostly to do with allowing time to flush out the >> vestiges of a dependency on some of the TLS 1.2 idiosyncrasies.. >> >> I would advocate for removing this statement and any residue of that >> sentiment from the draft. It's speculation and, even if it were true, it >> conveys the wrong message. The only message I would include is that one >> that is further down the document: "Any newer version of TLS is more secure >> than TLSv1.1." >> >> _______________________________________________ >> 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 >> > > > -- > > Best regards, > Kathleen > _______________________________________________ > 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