Re: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt)

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 10 July 2018 16:01 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 6DB8B130FF7 for <tls@ietfa.amsl.com>; Tue, 10 Jul 2018 09:01:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 xrJiDHhYT0Hf for <tls@ietfa.amsl.com>; Tue, 10 Jul 2018 09:01:52 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94365130FF5 for <tls@ietf.org>; Tue, 10 Jul 2018 09:01:52 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 32CF529B256; Tue, 10 Jul 2018 12:01:50 -0400 (EDT)
Date: Tue, 10 Jul 2018 12:01:50 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20180710160150.GD33554@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <CABkgnnUhC5O-XuPnxzgt-_T4pzw0MiwP3GYXYp45xFso8R2osA@mail.gmail.com> <20180710041755.GD85096@straasha.imrryr.org> <3161014.mNqxEOqjoE@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3161014.mNqxEOqjoE@pintsize.usersys.redhat.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/q1qm1wqeOhE_93c0KMOa60e1OsM>
Subject: Re: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.27
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, 10 Jul 2018 16:01:55 -0000

On Tue, Jul 10, 2018 at 03:38:42PM +0200, Hubert Kario wrote:

> The github version of the document points out that the security of TLS 1.2 
> downgrade protection to TLS 1.1 or TLS 1.0 depends on SHA-1.

Is this accurate?  TLS 1.0 uses a combined SHA-1 + MD5 PRF.  Are
there known attacks that compromise TLS 1.0 via collisions in its
PRF?

[ IIRC, one embarrassing feature of TLS 1.2 vs. TLS 1.0 is that in making
  the signature algorithms negotiable, it became possible to offer and
  use MD5 where previously TLS 1.0 used SHA-1. ]

> that is the downgrade issue in the protocol

Keep in mind that my example, illustrating potentially counter-productive
raising of the floor, was about SHA-1 signatures in certificates.
Does accepting SHA-1 signatures in *certificate chains* create
opportunities to downgrade TLS 1.2 to TLS 1.0?

For the record, I am not saying that users should not be moving to
TLS 1.2 (if they haven't already).  Rather, I'm not aware of practical
cryptographic downgrade attacks to TLS 1.0 (other than software
that might still pessimistically fall back to TLS 1.0 on TLS 1.2
handshake failure).

Absent, such downgrade attacks, what's really needed is broader
support for TLS 1.2 (raising the ceiling), which does not require
removal of support for TLS 1.0 (raising the floor).

As a community we're still prone to pursue improved security primarily
through removal of weak algorithms, and under-appreciate security
improvement via the introduction of stronger algorithms.

Of course removal of weak algorithms has its place, if these
facilitate downgrade attacks, or present unnecessary attack-surface
once no longer used.  But we should be careful to not rush into
overzealous deprecation that can sometimes do more harm than good.

-- 
	Viktor.