IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 27 October 2020 23:44 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 E1A133A08CD; Tue, 27 Oct 2020 16:44:08 -0700 (PDT)
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_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 NBOr7lrNw899; Tue, 27 Oct 2020 16:44:06 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 917153A08C5; Tue, 27 Oct 2020 16:44:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8660F389D2; Tue, 27 Oct 2020 19:50:44 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BV0WgKlfePGI; Tue, 27 Oct 2020 19:50:43 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3AEF0389B5; Tue, 27 Oct 2020 19:50:43 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4F1DC61B; Tue, 27 Oct 2020 19:44:03 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Daniel Migault <daniel.migault@ericsson.com>, iot-directorate@ietf.org, last-call@ietf.org, draft-ietf-tls-md5-sha1-deprecate.all@ietf.org, tls@ietf.org
In-Reply-To: <160380837029.27888.4435196327617929302@ietfa.amsl.com>
References: <160380837029.27888.4435196327617929302@ietfa.amsl.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 27 Oct 2020 19:44:03 -0400
Message-ID: <3981.1603842243@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fxY5TmZODPS2Z-4WI7oFwATfZIQ>
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: Tue, 27 Oct 2020 23:44:09 -0000

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

Certainly from an IOT point of view, an algorithm that has no code is more
secure than one with code.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email