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

Michael Richardson <> Thu, 26 September 2019 13:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 285F91208A9; Thu, 26 Sep 2019 06:50:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qy5658eFVvLW; Thu, 26 Sep 2019 06:50:41 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A680812018B; Thu, 26 Sep 2019 06:50:41 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 1D74238986; Thu, 26 Sep 2019 09:48:47 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 665C11582; Thu, 26 Sep 2019 09:50:40 -0400 (EDT)
From: Michael Richardson <>
To: John Mattsson <>
cc: "TLS\" <>, "saag\" <>
In-Reply-To: <>
References: <>
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: Thu, 26 Sep 2019 09:50:40 -0400
Message-ID: <16562.1569505840@localhost>
Archived-At: <>
Subject: Re: [saag] Lessons learned from TLS 1.0 and TLS 1.1 deprecation
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Sep 2019 13:50:50 -0000

First, I think that we must recognize that the *IETF* does not have the same
       sectoral powers that 3GPP has.  It is entirely appropriate what 3GPP
       did, and they seem to have learned the lessons they needed.

John Mattsson <>; wrote:
    > 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.

I think that we can more easily deprecate these individual ciphers and cipher
suites than we can entire TLS version numbers.

The mere fact that we had to "hide" the TLS 1.3 version in the header the way
that did speaks volumes to the problems in what I'll call the "secondary"
security industry.   There are significant incentives from enterprises to
have companies come to "patch up" their broken systems.   If we want
enteprises to move faster, and move with us, then we will have to spend more
time addressing the issues that they have.  We may not like their problems,
we may even strongly disagree, but we have to keep them in the tent.

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]        |   ruby on rails    [