[TLS] Intdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

Ted Lemon via Datatracker <noreply@ietf.org> Wed, 28 October 2020 15:56 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FBF3A09A8; Wed, 28 Oct 2020 08:56:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Ted Lemon via Datatracker <noreply@ietf.org>
To: int-dir@ietf.org
Cc: last-call@ietf.org, draft-ietf-tls-md5-sha1-deprecate.all@ietf.org, tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160390057302.19892.7954643072007013939@ietfa.amsl.com>
Reply-To: Ted Lemon <mellon@fugue.com>
Date: Wed, 28 Oct 2020 08:56:13 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/lbRMAcc9pF7U4OWz1MNcPEjZ8Mc>
Subject: [TLS] Intdir last call review of draft-ietf-tls-md5-sha1-deprecate-04
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 28 Oct 2020 15:56:19 -0000

Reviewer: Ted Lemon
Review result: Ready with Nits

This document is ready for publication, with one minor nit, which is included
at the end.

Éric additionally made the following request:
  As those hash algorithms were 'cheap' for TLS, I would appreciate a review of
  the impact if those algorithms are deprecated in TLS 1.2.

I am not in a position to do any practical tests, but I will point out several
things. First, deprecating MD5 is not going to cause a performance problem
because it's slower than SHA1, so we really only need to worry about whether
deprecating SHA1 will cause a problem. This document only deprecates SHA1 for
use in digital signatures. It "does not deprecate SHA-1 in HMAC for record
protection." Given the way TLS uses digital signatures, this should not be a
serious concern. At worst case, SHA256 is about 24% slower than SHA1. Best case
(shorter text) it is less than 16% slower. It's reasonable to expect that in
common use in TLS, the texts being digested will be shorter, not longer.
Further, the bulk of the computational burden of TLS is not in the generation
of digests for digital signatures. Therefore it seems reasonable to expect that
the performance impact of this change is vastly overshadowed by one of the very
factors that motivates it: the increased speed of hash computation over time. 
Even assuming constant speed legacy hardware, the performance impact is not
sufficient to cause concern when considering it as part of the total system
that would be using TLS 1.2.


In the abstract:
   The MD5 and SHA-1 hashing algorithms are steadily weakening in
   strength and their deprecation process should begin for their use in
   TLS 1.2 digital signatures.

Technically, the strength of these algorithms hasn't changed. What's changed is
that their strength is no longer sufficient to prevent realistic attacks. So it
might be better to say something like "The vulnerability of MD5 and SHA-1
algorithms to practical attacks is steadly increasing and ..."