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

mrex@sap.com (Martin Rex) Tue, 14 May 2019 20:53 UTC

Return-Path: <mrex@sap.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 CED9C120128 for <tls@ietfa.amsl.com>; Tue, 14 May 2019 13:53:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 ImXCAvyFzVqv for <tls@ietfa.amsl.com>; Tue, 14 May 2019 13:53:01 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15593120118 for <tls@ietf.org>; Tue, 14 May 2019 13:53:01 -0700 (PDT)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 453VJC0kXHz6F; Tue, 14 May 2019 22:52:59 +0200 (CEST)
X-purgate-ID: 152705::1557867179-0000020D-97A14CC5/0/0
X-purgate-size: 2456
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail07.wdf.sap.corp (Postfix) with ESMTPS id 453VJB2zfPzGp7W; Tue, 14 May 2019 22:52:58 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 5C457404C; Tue, 14 May 2019 22:52:58 +0200 (CEST)
In-Reply-To: <12276928.OsXPxM6NY9@pintsize.usersys.redhat.com>
References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <29960808.K0e8lGuAtk@pintsize.usersys.redhat.com> <20190514145249.C6DDB404C@ld9781.wdf.sap.corp> <12276928.OsXPxM6NY9@pintsize.usersys.redhat.com>
To: Hubert Kario <hkario@redhat.com>
Date: Tue, 14 May 2019 22:52:58 +0200
CC: mrex@sap.com, tls@ietf.org, Martin Thomson <mt@lowentropy.net>
Reply-To: mrex@sap.com
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20190514205258.5C457404C@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/LwvlHePI3OwgRZ3msE0AvcuJGYk>
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: Tue, 14 May 2019 20:53:04 -0000

Hubert Kario <hkario@redhat.com> wrote:
> 
> there are attacks, like BEAST, that TLS 1.0 is vulnerable to that
> TLS 1.1 and TLS 1.2 are not - that's a fact there are ciphersuites
> that are invulnerable to Lucky13 and similar style of attacks that
> can not be used with TLS 1.0 or TLS 1.1 - that's a fact

BEAST is an attack against Web Browsers (and the abuse known as SSL-VPNs),
it is *NO* attack against TLS -- whose design properties are described
in appendix F of rfc5246, and there is a trivial workaround for those
few apps that were affected.  Continued mentioning of BEAST really
only means one thing: severe crypto-cluelessness.

  http://www.educatedguesswork.org/2011/11/rizzoduong_beast_countermeasur.html

There are two things that BEAST showed:
   Running arbitrary attacker-supplied active content is a bad idea!
   Performing protocol version downgrade dances is a bad idea.

Lucky thirteen applies equally to all three:  TLSv1.0, TLSv1.1 and TLSv1.2,
but was a real-world issue only for borked implementations of DTLS (those
implementations that were providing a no-limits guessing oracle.


> 
> that doesn't sound to me like "ZERO security benefit",

You seem to be confusing the difference between
  (1) ensuring that TLSv1.2 support is enabled
with
  (2) disabling TLSv1.0 + TLSv1.1 support.

If you do (1), then (2) does not add security benefits.

> 
>> On digitally_signed, is proven that TLSv1.2 as defined by rfc5246
>> is the weakest of them all.
> 
> yes, provided that:
>  - MD5 is actually in use
>  - or Joux does not hold and MD5+SHA1 is _meaningfully_ stronger[1]
>     than SHA-1 alone *and* SHA-1 is actually in use

MD5 || SHA-1  is **ALWAYS** meaninfully stronger than SHA-1 alone, *NO* if!

>  
>> The POODLE paper
>>    https://www.openssl.org/~bodo/ssl-poodle.pdf
>> 
>> asserts that many clients doing downgrade dances exist, and at the
>> time of publication, this includes Mozilla Firefox, Google Chrome and
>> Microsoft Internet Explorer.
> 
> either we consider clients that haven't been updated for half a decade now to 
> be of importance, then disabling support for old protocol versions has 
> meaningful security benefit, or we ignore them as they include insignificant 
> percentage of users and are vulnerable to much easier attacks anyway
> 
> so, which way is it?

MSIE seems to still be doing downgrade dances _today_, btw.


-Martin