Re: [TLS] [saag] Lessons learned from TLS 1.0 and TLS 1.1 deprecation
Michael Richardson <mcr+ietf@sandelman.ca> Tue, 01 October 2019 17:19 UTC
Return-Path: <mcr+ietf@sandelman.ca>
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 F00DF120971; Tue, 1 Oct 2019 10:19:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 p43tQAVDzWXs; Tue, 1 Oct 2019 10:19:49 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 119251209C1; Tue, 1 Oct 2019 10:19:38 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9E9733897A; Tue, 1 Oct 2019 13:17:36 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AFDF5D9A; Tue, 1 Oct 2019 13:19:37 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "TLS@ietf.org" <TLS@ietf.org>, "saag@ietf.org" <saag@ietf.org>
In-Reply-To: <F1D7BC9F-0CC7-459C-A338-DD54F5513EF3@ericsson.com>
References: <BF5F63A6-105B-47C6-8B65-29A290A16E76@akamai.com> <8B2B78CF-F312-4F7A-8EB1-A712F309A754@gmail.com> <F1D7BC9F-0CC7-459C-A338-DD54F5513EF3@ericsson.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 01 Oct 2019 13:19:37 -0400
Message-ID: <27914.1569950377@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/4C11VIgSdXBSm5Ng6Uv5W0am2Jg>
Subject: Re: [TLS] [saag] 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 17:19:52 -0000
John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org> 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 guess this is on outward facing web sites. Does it say which cipher suites are required, and certificate chains are required? (TLS 1.3 with RSA-1024+SHA1 certificates would be dumb) Does it say that *only* TLS 1.3 is to be supported? Does it say anything about outgoing connections supporting APIs and the like? > 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. But, it's so incredibly context sensitive. > - The second thing is to do like 3GPP and mandate support for TLS 1.3 > in new implementations and deployments. But, the IETF doesn't really write requirements like this. > 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. Deprecating it from new work is not the same as removing it from implementations. My question above about *only* has to do with the knock-on effect. Entity XYZ keeps 1.2 (or 1.1) available because API FOO is used by entity BAR, which can not upgrade to 1.3 today. Entity BAR never experiences pain, never upgrades, and nobody is sure when/if they can turn off 1.2. This is a bit of a variation of the "Postel principal is bad" situation. One thing that entities like NIST could require is that compliant organizations report, in the years leading up to 2024, and after, to log and report the proportion of TLS version that connect. How can the IETF help? *An IETF standard for logging TLS connection parameters would help here* -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [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