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

Sean Turner <sean@sn3rd.com> Wed, 28 October 2020 00:49 UTC

Return-Path: <sean@sn3rd.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 E925E3A0AC5 for <tls@ietfa.amsl.com>; Tue, 27 Oct 2020 17:49:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 gXwpYk6TW9Fj for <tls@ietfa.amsl.com>; Tue, 27 Oct 2020 17:49:25 -0700 (PDT)
Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 3450C3A0AC1 for <tls@ietf.org>; Tue, 27 Oct 2020 17:49:25 -0700 (PDT)
Received: by mail-qv1-xf29.google.com with SMTP id bl9so1637947qvb.10 for <tls@ietf.org>; Tue, 27 Oct 2020 17:49:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uNPAfK+lUagagS8IFXeWA/ZkAd2KVug5AnvYKaTn7aE=; b=U62v2hFe4wpu/tz53NNNhEgSGQ0n0khgrGGAqilfJomo1g29ZwmF6hMexDeG2PaX/o tjnigL75+B3H7+nZwgOVvtSjIxj0B0etaabWfxvs48LoLSQMUCSJqB6KjA/E0CLp7jpu xie293L/Hv7USO8GVQsiUJavUuu/AzmRVREMQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uNPAfK+lUagagS8IFXeWA/ZkAd2KVug5AnvYKaTn7aE=; b=KoToMKCbs+xPu6WnJ+bu21UF/f2DmdLzRvLh9Eo5NmP36/YJWiOBIBmSXAjy88z3JT zpLb157kQFhGwphLpS/01GuoiZEvTwwJ3vnO0csUwP+av+loijZeZ/SbMiLCx51Spyuz HJFlIo5nxgBntZtO61lbgquDrgxbZ5VWxo2U8vBRk+AfkQ4UcqSQFqQTw9cp7o+AxmqO pfghrHjxpHucjCd9dp2G2daL0Y1DEffnu1ckG1kMh10y3SWJHW4fo/Jzp75UJ9SiP/K/ x2PY8/2NzcBEBe7mMY0CrXWF61GAPMHV5RUZyaFDzVKOdZK7VmbFUEDlTF2vq7STWC1U K5kw==
X-Gm-Message-State: AOAM531+ONujgAnbsjlSiqVrGXCCRYnhqW8gs9dtWeT1P1pM+CnvU94S gYpu2ZDWGf7ML1nrC5umVh/nug==
X-Google-Smtp-Source: ABdhPJwEMTenq+kHBKeV//wqt8FrvrrZglygZTqxG6YVSU7vtJbYSNzdkHg7bq0EeQ/MfcS/R/vzFQ==
X-Received: by 2002:a05:6214:146e:: with SMTP id c14mr5440622qvy.22.1603846164168; Tue, 27 Oct 2020 17:49:24 -0700 (PDT)
Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id p13sm1878856qkj.58.2020.10.27.17.49.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Oct 2020 17:49:23 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <3981.1603842243@localhost>
Date: Tue, 27 Oct 2020 20:49:22 -0400
Cc: Daniel Migault <daniel.migault@ericsson.com>, iot-directorate@ietf.org, last-call@ietf.org, draft-ietf-tls-md5-sha1-deprecate.all@ietf.org, TLS List <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6ABB3979-8A6B-4765-830F-47998E319C08@sn3rd.com>
References: <160380837029.27888.4435196327617929302@ietfa.amsl.com> <3981.1603842243@localhost>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/LbxyF1ccjl0ZyTKzf55mScv7ZzM>
Subject: Re: [TLS] [Last-Call] Iotdir 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: Wed, 28 Oct 2020 00:49:27 -0000


> On Oct 27, 2020, at 19:44, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> <#secure method=pgpmime mode=sign>
> 
> Daniel Migault via Datatracker <noreply@ietf.org> wrote:
>> RFC6194 may be mentioned as a reference for
>> not deprecating HMAC-SHA-1 as well as an
>> additional reference to [NISTSP800-131A-R2].
> 
>> Reading the text the situation of HMAC with
>> MD5 is unclear. Since we specify that SHA-1
>> is not deprecated for HMAC we may specify
>> the status for HMAC with MD5. Given RFC6151 I
>> hope the reason is that MD5 and HMAC-MD5 has
>> already been deprecated but I have not found
>> this. Maybe that would worth mentioning it
>> is deprecated already.
> 
> My understanding is that despite the flaws in MD5, HMAC-MD5 is still
> resistant to second pre-image attacks.
> RFC6151 is pretty clear about the state of things,

Well it was the state of things in 2011. But, I am pretty sure we have heard something by now (or this thread will prompt a response from somebody who knows more).

> but let me tell you about
> the hassle of explaining this to end users.
> The two rounds that the HMAC construct uses mean that only way to get past it
> is with a brute force attack.
> 
> I rememeber back in 1995ish, when Hugo insisted with do HMAC.
> We hated it because it made hardware.  He clearly knew something!
> 
> I agree that this document should probably quote more of RFC6151 when it
> comes to HMAC-MD5.
> 
> My best advice for why we deprecate HMAC-MD5 (and HMAC-SHA1) is because end
> users are confused and/or alarmed if the strings "MD5" or "SHA1" occur in
> their logs.


This was the reason I wrote RFC 7093 (Additional Methods for Generating Key Identifiers Values), which ended up going through the ISE stream. I wanted to avoid having to explain that key identifiers were generated with SHA-1 but that was okay. Better to just avoid the darn algorithm.

spt