Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" (Martin Rex) Thu, 09 May 2019 22:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 588D11200F8 for <>; Thu, 9 May 2019 15:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qjooDKoWHzp6 for <>; Thu, 9 May 2019 15:24:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E43C1200EC for <>; Thu, 9 May 2019 15:24:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 450SZV177zzyR5; Fri, 10 May 2019 00:24:50 +0200 (CEST)
X-purgate-ID: 152705::1557440690-00000218-9DA1C408/0/0
X-purgate-size: 4645
X-purgate: clean
X-purgate: This mail is considered clean (visit for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R)
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ( []) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 450SZT4xSGzGnyX; Fri, 10 May 2019 00:24:49 +0200 (CEST)
Received: by (Postfix, from userid 10159) id 9C553404C; Fri, 10 May 2019 00:24:49 +0200 (CEST)
In-Reply-To: <>
References: <> <> <> <>
To: Hubert Kario <>
Date: Fri, 10 May 2019 00:24:49 +0200 (CEST)
CC:,, Martin Thomson <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
From: (Martin Rex)
Archived-At: <>
Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 May 2019 22:24:57 -0000

Hubert Kario <> wrote:
>On Wednesday, 8 May 2019 02:31:57 CEST Martin Rex wrote:
>> Hubert Kario <> wrote:
>>>> Thanks to Peter Gutmann for the summary:
>>>> which you may have missed.
>>> yes, Joux paper also shows that attacking MD5||SHA1 is harder than
>>> attacking SHA1 alone
>>> but that doesn't matter, what matters is _how much harder it is_ and Joux
>>> paper says that it's less than a work factor of two, something also knows
>>> as a "rounding error" for cryptographic attacks
>> collision attacks and real-time 2nd preimage attacks on randomly keyed
>> hashes are substantially different things.
>> simple math seems hard.
>> TLSv1.0 + TLSv1.1 both use   (rsa, MD5||SHA1)
>> TLSv1.2 (rfc5246) permitted (rsa, MD5) and allows (rsa,SHA1)
> side note on that, with ECDSA, all three versions use (ecdsa, sha1) so 
> everything we are discussing applies to RSA and RSA only

(EC)DSA is fatally flawed (design flaw), no-one should be using it.
EdDSA once it becomes available, might be OK.

I guess that all existing TLS implementations with ECDSA support might
be leaking (enough info to compute) the ECDSA private key to a mere passive
observer of a few thousand full TLS_ECHDE_ECDSA_ handshakes.

> MD5 was deprecated and removed by basically every library
> and can't be used in TLS 1.2, I specifically meant SHA1

MD5 deprecated ?  Nope, glaring emtpy:

MD5 removed ? Mostly, but several implementors had to be prodded with
              with CVE-2015-7575 (SLOTH) to remove it.

The real issue at hand is:

  Prohibiting TLSv1.0 and TLSv1.1 is going to result in lots of
  interop problems, while at the same time providing *ZERO*
  security benefit.

  The installed base of software which is limited to TLSv1.0
  for outgoing TLS-protected communication is huge.

  What *WOULD* provide *HUGE* benefit, would be to remove the
  dangerous "protocol version downgrade dance" from careless applications,
  that is the actual problem known as POODLE, because this subverts the
  cryptographic procection of the TLS handshake protocol.

  We've known this downgrade dance to be a problem since the discussion
  of what became rfc5746.  Prohibiting automatic protoocol version
  downgrade dances is going to ensure that two communication peers
  that support TLSv1.2 will not negotiate a lower TLS protocol version.

  If applications doing downgrade dances had at least a basic amount
  of risk management, and would refuse to perform an unlimited amount
  of downgrades automatically and secretly, then everyone would be
  much better of.

  I've seen web browsers doing this entirely without risk management,
  and wasn't there some Java class which also did this?

And PLEASE stop unconditionally bashing SHA-1

I am constantly seeing crypto-clueless folks, including some national
governmental agencies, that are giving out their own TLS recommendations,
which are typically sterile of scientific rationale, and it's pretty
obvious those folks either haven't read US NIST SP 800-57 part 1 rev.4
or not understood it.  In particular Table 3 on top of page 54, about
the signficant difference between sha1WithRsaEncryption and HMAC-SHA1
e.g. when used for integrity protection by a TLS cipher suites such
as the TLSv1.2 MTI cipher suite TLS_RSA_WITH_AES_128_CBC_SHA.

Security      Digital Signatures and       HMAC, Key Derivation Functions
Strength      hash-only applications       Random Number Generation

no <=80 no no no no  SHA-1  no no no no no no no no no no no no no no

  112      SHA-224,SHA-512/224,SHA3-224

  128      SHA-256,SHA-512/256,SHA3-256           SHA-1

  192          SHA-384,SHA3-384              SHA-224,SHA-512/224

 >=256         SHA-512,SHA3-512            SHA-256,SHA-512/256,SHA-384
                                                SHA-512, SHA3-512

In particular, if you compare HMAC-SHA1 to the shorter&weaker GMAC integrity
protection afforded by AES-GCM cipher suites (rfc5288,rfc5289)
or the even shorter&weaker integrity protection afforded
by AES-CCM cipher suites (rfc6655).

Lots of folks erroneously believe that
and more so

would provider stronger integrity protection than


while in reality, it is just the opposite.