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

Benjamin Kaduk <kaduk@mit.edu> Sun, 01 November 2020 18:09 UTC

Return-Path: <kaduk@mit.edu>
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 D7C6A3A0CB3; Sun, 1 Nov 2020 10:09:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 W-1YhJcOStnw; Sun, 1 Nov 2020 10:09:35 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 407273A0CB2; Sun, 1 Nov 2020 10:09:34 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0A1I9PNH025881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 1 Nov 2020 13:09:31 -0500
Date: Sun, 1 Nov 2020 10:09:25 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Ted Lemon <mellon@fugue.com>
Cc: int-dir@ietf.org, last-call@ietf.org, draft-ietf-tls-md5-sha1-deprecate.all@ietf.org, tls@ietf.org
Message-ID: <20201101180925.GR39170@kduck.mit.edu>
References: <160390057302.19892.7954643072007013939@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <160390057302.19892.7954643072007013939@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Swgj-pMwD7I7OHwWXJPX-Fr9rzs>
Subject: Re: [TLS] Intdir last call review of draft-ietf-tls-md5-sha1-deprecate-04
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: Sun, 01 Nov 2020 18:09:37 -0000

Hi Ted,

Thanks for the review, especially for thinking about the point that Éric
requested.

I don't really agree with your nit, though, as there have been improved
crypanalysis and correspondingly improved cryptographic attacks on both
algorithms over time (SHA1 more recently than MD5).  Increased
computational power to take advantage of those cryptographic weaknesses is
certainly a factor in moving to deprecate the vulnerable algorithms, but it
is not the only factor.

-Ben

On Wed, Oct 28, 2020 at 08:56:13AM -0700, Ted Lemon via Datatracker wrote:
> 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.
> 
> Nit:
> 
> 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 ..."
> 
> 
>