[COSE] Barry Leiba's Yes on draft-ietf-cose-hash-algs-04: (with COMMENT)
Barry Leiba via Datatracker <noreply@ietf.org> Tue, 02 June 2020 04:33 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: cose@ietf.org
Delivered-To: cose@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB3B3A02C1; Mon, 1 Jun 2020 21:33:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-cose-hash-algs@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Ivaylo Petrov <ivaylo@ackl.io>, ivaylo@ackl.io
X-Test-IDTracker: no
X-IETF-IDTracker: 7.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <159107239537.28693.16065000145824637198@ietfa.amsl.com>
Date: Mon, 01 Jun 2020 21:33:15 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/UV_H2q5Z71wwg_6qsF13vEDFW5Q>
Subject: [COSE] Barry Leiba's Yes on draft-ietf-cose-hash-algs-04: (with COMMENT)
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.29
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2020 04:33:16 -0000
Barry Leiba has entered the following ballot position for draft-ietf-cose-hash-algs-04: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- — Abstract — There are however circumstances where hash algorithms are used, such as indirect signatures where the hash of one or more contents are signed, and X.509 certificate or other object identification by the use of a fingerprint. I found this hard to parse, and had to read it a few times. How about this?: NEW There are, however, circumstances where hash algorithms are used, such as in indirect signatures, where the hash of some content is signed, and for fingerprinting of X.509 certificates or other objects. END — Introduction — This omission was intentional as a structure consisting of just a digest identifier, the content, and a digest value does not by itself provide any strong security service. Nit: this needs a few more commas... one after “intentional”, and one before and one after “by itself”. One of the primary things that has been identified by a hash function for secure message is a certificate. Another that I had trouble parsing. Maybe, “One of the primary things related to secure messages that has been identified by a hash function is a certificate.” — Section 2 — hash functions is part of the base design as cryptographic advances are sure to reduce the strength of a hash function. Nit: this needs a comma after “design”. The standard "Collision Attack" is one where an attacker can find two different messages that have the same hash value. If a collision attack exists, then the function SHOULD NOT be used for a cryptographic purpose. I’m uncomfortable with having this document give a brief tutorial on cryptographic hashing, as it has to be oversimplified... and it is. If it’s going to stay, I’d like to see ar least one minor change, though I’ll defer to the Sec ADs on this point: for any hash alg, it is always possible to encounter a collision, and the text isn’t clear about what “if a collision attack exists” really means. I think it means not to use it if a collision attack is practical, and maybe this is a better way to say it?: NEW A "collision attack" is one where an attacker can find two different messages that have the same hash value. A hash function that is susceptible to collision attacks, SHOULD NOT be used for cryptographic purposes. END checked to see if they are the correct one. “They are the correct one?” Oof. How about, “to find the correct one,” or (maybe better), “to see if they are suitable.”? If the fingerprint is used to verify that it is the correct certificate, then that usage is subject to a collision attack as above. If however, the fingerprint is used to sort through a collection of certificates “then that usage is a cryptographic one and is subject to the warning above about collision attacks.” And “however” also needs a comma before it, as well as after. In this case, one still needs to validate that the public key validates the signature Make the first “validate” say “confirm” instead, to avoid the awkward double use of “validate”. To distinguish between these two cases, a new value in the recommended column of the COSE Algorithms registry is to be added. "Filter Only" indicates that the only purpose of a hash function should be to filter results and not those which require collision resistance. Might it be better to have the new column be called “cryptographic use”, with values of “yes” and “no”? Hint: I think it would. Hint#2: this is a non-blocking comment, so you might disagree. — Section 2.1 — * Additional data, this can be something as simple as a random value Nit: make the comma a semicolon. appending to the content, but it is strongly suggested to it Nit: change “to it” to “that it”. — Section 3.1 — Because of the known issues for SHA-1 and the fact that is should no Nit: change “that is” to “that it”. — Section 3.2 — Locations that use this hash function need either to analysis the potential problems with having a collision occur, or where the only function of the hash is to narrow the possible choices. Locations? And do you mean to use “analysis” as a verb? Maybe this?: NEW Use of this hash function needs analysis of the potential problems with having a collision occur, or must be limited to where the function of the hash is non-cryptographic. END — Section 3.3 — One of the benefits of this differences is that when computing a shorter SHAKE hash value Nit: “difference”, singular. — Section 5 — that need the cryptographic properties, i.e. collision resistance, and properties that correspond to possible object identification. Collision resistance isn’t the only cryptographic property (there’s also, for example, preimage resistance), so change “i.e.” to “such as”. This is another example of the hazard of trying to explain hashing in a simple document such as this one. This is the difference between collision resistance and second pre-image resistance. If you have collision resistance, don’t you automatically have second preimage resistance? What’s he point of mentioning second preimage resistance here, when you don’t mention it nor need it anywhere else? are under constant attack and the strength of hash algorithms will be reduced over time. I would say “the cryptographic strength”.
- [COSE] Barry Leiba's Yes on draft-ietf-cose-hash-… Barry Leiba via Datatracker
- Re: [COSE] Barry Leiba's Yes on draft-ietf-cose-h… Jim Schaad
- Re: [COSE] Barry Leiba's Yes on draft-ietf-cose-h… Barry Leiba
- Re: [COSE] Barry Leiba's Yes on draft-ietf-cose-h… Roman Danyliw
- Re: [COSE] Barry Leiba's Yes on draft-ietf-cose-h… Jim Schaad