Re: [DNSOP] RFC 2845bis and HMAC-MD5

Dick Franks <rwfranks@acm.org> Thu, 14 March 2019 19:04 UTC

Return-Path: <rwfranks@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5E7130F0D for <dnsop@ietfa.amsl.com>; Thu, 14 Mar 2019 12:04:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.647
X-Spam-Level:
X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 IkMKBkki4GSs for <dnsop@ietfa.amsl.com>; Thu, 14 Mar 2019 12:04:19 -0700 (PDT)
Received: from mail-it1-f175.google.com (mail-it1-f175.google.com [209.85.166.175]) (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 8DBAD130EF2 for <dnsop@ietf.org>; Thu, 14 Mar 2019 12:04:19 -0700 (PDT)
Received: by mail-it1-f175.google.com with SMTP id 188so6826816itb.0 for <dnsop@ietf.org>; Thu, 14 Mar 2019 12:04:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GgIGi4KY6EescNqcUpbJiHfCT5PtE07CTCUL2vgpwm8=; b=E9Y12nk+kCIZmDs/D/eBXajwW4XHYxWq3GuhR/7h9an+1WDoU8IG7iD7KOGTnGwrwa 7R+adKIKRrkxOQL2JbsEDmq0xz2VKUy83YWBBwPkVc6CSx8uWxfyILD/MbazN9XMFwRw euQlwKZM4ZI4D6uF6lm6nB5onhnTPkEFxMh+zQUUAiZl8TYtilK2vLZ8wmwXuWQJjlS/ r1M9loAJi53m9u6t7Cxo6alZZfl5f+s7xpdUqP4kOvaflrygYJkl2UMRhU7ScevrqDJr RCGVRi+rjb8PwFD+cqGU+mdLnEyXvXA9faTFg+4t+hbGPVfkIyhfraZI9PZskFvqresh BMUw==
X-Gm-Message-State: APjAAAUXh5sxws5FD17JTutKcV6V9lWVjpKXoD9zb5yC7WltLVP+8bh2 pbBl/rjXVqErGivEGX8QzMLBaMYCEzAQr+tQVa8=
X-Google-Smtp-Source: APXvYqwd6Wy01f36SJBVulpBcGRipR0bkl/9u16SuGSHHlY5HlArF1lOpKD6k1wt7vmh2boHpLvU3w+cZzlk87KcxVg=
X-Received: by 2002:a02:c893:: with SMTP id m19mr14014935jao.28.1552590258657; Thu, 14 Mar 2019 12:04:18 -0700 (PDT)
MIME-Version: 1.0
References: <20190314155324.4841ce29@glaurung.nlnetlabs.nl> <alpine.DEB.2.20.1903141507190.13313@grey.csi.cam.ac.uk>
In-Reply-To: <alpine.DEB.2.20.1903141507190.13313@grey.csi.cam.ac.uk>
From: Dick Franks <rwfranks@acm.org>
Date: Thu, 14 Mar 2019 19:03:42 +0000
Message-ID: <CAKW6Ri7RVUQ8wF8NuSKtwEMdKEKXjGz2hUxcaHiQBU7i-kYFtg@mail.gmail.com>
To: Tony Finch <dot@dotat.at>
Cc: Martin Hoffmann <martin@opennetlabs.com>, IETF DNSOP WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d960810584129648"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/MKPe_IZ4CCaXR91V3oSNCzxlDWQ>
Subject: Re: [DNSOP] RFC 2845bis and HMAC-MD5
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2019 19:04:22 -0000

On Thu, 14 Mar 2019 at 15:09, Tony Finch <dot@dotat.at>; wrote:

> Martin Hoffmann <martin@opennetlabs.com>; wrote:
> >
> > As such, I would like to propose to move HMAC-MD5 to optional and only
> > retain SHA-1 and SHA-256 as mandatory.
>
> That seems sensible. There should at the very least be a reference to
> RFC6151, Updated Security Considerations for the MD5 Message-Digest and
> the HMAC-MD5 Algorithms.


Is there any continuing justification for the special treatment of SHA-1
enshrined
in the footnote to Table 1.

Section 8 make abundantly clear that algorithm selection and applicable
truncation
is a matter of policy and agreement between client and server.  Taken
together with
the detailed requirements in section 6.5.2.1, and the statement that a
reply SHOULD
be sent with a MAC at least as long as that in the corresponding request,
removes
the need for specific numerical length constraints to be stated in this
document.

IMHO the SHOULD here should become MUST, promoting this to a full
requirement.

The special cases identified in 6.5.1 and 6.5.2 are obviously not subject
to the
general policy.

Security conscious users will define their policy having regard to
performance and
size versus strength trade-offs and weaknesses of particular algorithms
about which
there is no shortage of published material.

                 Requirement Name
                   ----------- ------------------------
                   Mandatory   HMAC-MD5.SIG-ALG.REG.INT
                   Optional    gss-tsig
                   Mandatory   hmac-sha1
                   Optional    hmac-sha224
                   Mandatory   hmac-sha256
                   Optional    hmac-sha384
                   Optional    hmac-sha512

                                  Table 1

   SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.



--Dick