[secdir] Secdir last call review of draft-ietf-cose-hash-algs-06

Brian Weis via Datatracker <noreply@ietf.org> Tue, 07 July 2020 02:53 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B273A0963; Mon, 6 Jul 2020 19:53:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Brian Weis via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: last-call@ietf.org, draft-ietf-cose-hash-algs.all@ietf.org, cose@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.7.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159409038799.11728.3735557601340694961@ietfa.amsl.com>
Reply-To: Brian Weis <bew.stds@gmail.com>
Date: Mon, 06 Jul 2020 19:53:08 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/r7QYD_rpnKuQOEnQcPMVo7uMlp4>
Subject: [secdir] Secdir last call review of draft-ietf-cose-hash-algs-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jul 2020 02:53:08 -0000

Reviewer: Brian Weis
Review result: Ready

This is a very tardy security considerations review; many apologies to the ADs
and the author. After reviewing draft-ietf-cose-hash-algs-06 I have only two
minor wording suggestions, which Jim can choose to implement or not.

(1) Referencing BCP 201 in the second paragraph of Section 2 was a good
addition to this sentence:
   Applications should also make sure that the ability to change
   hash functions is part of the base design, as cryptographic advances
   are sure to reduce the strength of a hash function [BCP201].

But reading the BCP does point out that perhaps the current wording is not
precise.  I have always considered “cryptographic advances” as the
strengthening of algorithms or development of new stronger algorithms rather
than increased success of attacks on algorithms. The BCP uses the wording
"advances in computing power or advances in cryptoanalytic techniques” to
describe this phenomenon. Maybe “cryptographic advances” could be replaced with
that phrase from the BCP, or at least change “cryptographic” to “cryptanalytic”.

(2) Security Considerations describes two properties of a hash function. By the
time the reader gets to this section they should well understand what is
collision resistance. But  then second pre-image resistance is mentioned
offhand without any explanation. Adding a parenthetical definition for second
pre-image resistance would be helpful to the reader. For example, by adding
“(i.e., where it is computationally infeasible to find any second input which
has the same output as that of a specified input)” to the end of the sentence.
(This text was lifted from the Wikipedia “Preimage attack” article.)