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

Ted Lemon <mellon@fugue.com> Sun, 01 November 2020 21:53 UTC

Return-Path: <mellon@fugue.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 AF95A3A097C for <tls@ietfa.amsl.com>; Sun, 1 Nov 2020 13:53:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 vOHlt5y79vvK for <tls@ietfa.amsl.com>; Sun, 1 Nov 2020 13:53:45 -0800 (PST)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12773A0983 for <tls@ietf.org>; Sun, 1 Nov 2020 13:53:45 -0800 (PST)
Received: by mail-qk1-x731.google.com with SMTP id z6so10018241qkz.4 for <tls@ietf.org>; Sun, 01 Nov 2020 13:53:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=ISk9KTcm6/gengRlF1KwFyjVyAi6oUB6TGo9fa5AfUM=; b=gXM9dlZ5tAP1WmRQy4j6P8G4hKKdNKXdq5ckIe5hrBtq4OK/r/dZI5VobqavOlBnbG 1OEkiduxY8v3t2wNmo9PH5I046fujWoZqKlhI9lmqDxCDwesJd0SpR1vI+KBzkk4LiOC 6zrpkKQV9wa9TDAnKdQEsK9wdz+cJS7ZLqmyD5sIbcOqucQz46VCRXbozFdf411KaPgv CeB6cFOO8IeGs1JkofIF7JJAxKE8ENTC43s+8AKQJQ4CGhDx3MdUlUyJajsEQxqdMy4e uDRoPQ/EARKOMw+OYIsAA92KqiQodSO0sCqFVAAwQ2p1U/e3G2oSdHfJCak+ADd5Jg2U FzNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=ISk9KTcm6/gengRlF1KwFyjVyAi6oUB6TGo9fa5AfUM=; b=LKgtCFYSnblAd51PcFf4wldE/KjeSZqfzYaic4gUVfChHZkzza4hrB5Z8n72cT1zFI mnjtQo/o3AasWdW5Mm+kyN9y4bppNui2rp7ATvcoiZRU7DwuS6NA5nwBBwam5Bd9rTvW CvlQoRz0/B4tYg1g2yzMdqGH1eY08rOvR5V8BuUyaBkzBK2RAjT1cqyqcXNdAujBWhgZ 1TMaQS/rKJd6IZWUyX6CRiuq+eAzx4Nv1U7IbEPJGOxuVrwrgYKuTRoCg3FPfQ3qolsf gHO9pxR/t0Ndvhmt9/qnz8N7I1vAfBnTwA1GH9LOgelmK70PkWg7abiq/Cc4Dt48Yala jD4A==
X-Gm-Message-State: AOAM532gTFZGfA34UZSC2idrINurhZRus4EQ0y7VWYhfPse12KE9dIYu JrEpEdTqDkxxLRWX6OlzO+qunwQ3hBOOLQ==
X-Google-Smtp-Source: ABdhPJz0SZ9co57cb2Vvg2oVdcBJCLNrdR8H00bVzdsn/iLaF7ukFHwl6a6NheMdoyQ+spVkuWrr7g==
X-Received: by 2002:a37:6fc5:: with SMTP id k188mr12412992qkc.317.1604267624169; Sun, 01 Nov 2020 13:53:44 -0800 (PST)
Received: from [192.168.4.114] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id o187sm6646293qkb.120.2020.11.01.13.53.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Nov 2020 13:53:43 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Ted Lemon <mellon@fugue.com>
Mime-Version: 1.0 (1.0)
Date: Sun, 01 Nov 2020 16:53:41 -0500
Message-Id: <558A253B-FB53-4B00-9C67-9DF7AA37C952@fugue.com>
References: <20201101180925.GR39170@kduck.mit.edu>
Cc: int-dir@ietf.org, last-call@ietf.org, draft-ietf-tls-md5-sha1-deprecate.all@ietf.org, tls@ietf.org
In-Reply-To: <20201101180925.GR39170@kduck.mit.edu>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: iPhone Mail (18B84)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1UynLbctc94Zo6vZfMbxILRam1E>
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 21:53:48 -0000

FWIW my nit was simply that algorithms aren’t getting weaker: attacks are getting stronger. Sorry if I worded the suggested text badly. 

> On Nov 1, 2020, at 13:09, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> 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 ..."
>> 
>> 
>>