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 =-