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

Hubert Kario <hkario@redhat.com> Tue, 10 July 2018 18:39 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 0DD9813104D for <tls@ietfa.amsl.com>; Tue, 10 Jul 2018 11:39:33 -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 HAyeD84hG1EC for <tls@ietfa.amsl.com>; Tue, 10 Jul 2018 11:39:31 -0700 (PDT)
Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0348B131047 for <tls@ietf.org>; Tue, 10 Jul 2018 11:39:31 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4BDF481663F2; Tue, 10 Jul 2018 18:39:30 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id BB9052026D6B; Tue, 10 Jul 2018 18:39:29 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Tue, 10 Jul 2018 20:39:28 +0200
Message-ID: <9695281.VezRcJznyJ@pintsize.usersys.redhat.com>
In-Reply-To: <20180710160150.GD33554@straasha.imrryr.org>
References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <3161014.mNqxEOqjoE@pintsize.usersys.redhat.com> <20180710160150.GD33554@straasha.imrryr.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1598888.fIEWTU1gaR"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 10 Jul 2018 18:39:30 +0000 (UTC)
X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 10 Jul 2018 18:39:30 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:''
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_Laki0O-Fthw87XlxbNZ0p17Vus>
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 18:39:33 -0000

On Tuesday, 10 July 2018 18:01:50 CEST Viktor Dukhovni wrote:
> 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?

that's what SLOTH was about (among other things)

> [ 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?

ah, then I misunderstood, sorry

for certificates, the answer is "not immediately", and "harder"

as that requires either the ability by attacker to get a cert from an internal 
CA (that it can the calculate collision for) or a preimage attack on SHA-1 
signatures (which is significantly harder than chosen prefix)

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

do we have access to other incentives than breaking compatibility with old 
stuff?

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

aren't new strong algorithms only effective when they are actually used 
though?

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

my opinion is that published RFCs should represent _current_ best practice, if 
only because we will have to live with stuff that is deployed new for 10 years 
if not more
-- 
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