Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

Hubert Kario <hkario@redhat.com> Mon, 13 May 2019 11:30 UTC

Return-Path: <hkario@redhat.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 B1E35120122 for <tls@ietfa.amsl.com>; Mon, 13 May 2019 04:30:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXGTxcIPnoaY for <tls@ietfa.amsl.com>; Mon, 13 May 2019 04:30:27 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7A2120121 for <tls@ietf.org>; Mon, 13 May 2019 04:30:27 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B2D9D37E79; Mon, 13 May 2019 11:30:26 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (ovpn-200-37.brq.redhat.com [10.40.200.37]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8EA4663BB4; Mon, 13 May 2019 11:30:25 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: mrex@sap.com
Cc: tls@ietf.org, Martin Thomson <mt@lowentropy.net>
Date: Mon, 13 May 2019 13:30:24 +0200
Message-ID: <29960808.K0e8lGuAtk@pintsize.usersys.redhat.com>
In-Reply-To: <20190509222449.9C553404C@ld9781.wdf.sap.corp>
References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <14984380.sTCEapK0kV@pintsize.usersys.redhat.com> <20190509222449.9C553404C@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1978465.3IOum5hbF4"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 13 May 2019 11:30:26 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WFMgq18y9bjmsFFNyM6KE-GP2fw>
Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"
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: Mon, 13 May 2019 11:30:29 -0000

On Friday, 10 May 2019 00:24:49 CEST Martin Rex wrote:
> Hubert Kario <hkario@redhat.com> wrote:
> > 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:
>               https://www.rfc-editor.org/errata_search.php?rfc=5246
> 
> MD5 removed ? Mostly, but several implementors had to be prodded with
>               with CVE-2015-7575 (SLOTH) to remove it.

I meant in practice

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

that's your opinion, not an established fact

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

which exact piece of popular software actually still does that? It ain't curl, 
it ain't Chrome, it ain't Firefox. It also isn't something done automatically 
by any TLS implementation that's even remotely popular: OpenSSL, NSS, GnuTLS, 
schannel, Secure Transport, go...

>   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

that's a strawman, I was talking about SHA-1 signatures

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic