> -----Original Message-----
> From: COSE <[email protected]> On Behalf Of Benjamin Kaduk via
> Datatracker
> Sent: Wednesday, June 10, 2020 10:56 PM
> To: The IESG <[email protected]>
> Cc: [email protected]; [email protected];
[email protected];
> [email protected]
> Subject: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-hash-algs-04:
(with
> DISCUSS and COMMENT)
>
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-cose-hash-algs-04: Discuss
>
> 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/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> In Section 3.3:
>
> The SHA-3 hash algorithms have a significantly different structure
> than the SHA-2 hash algorithms. One of the benefits of this
> differences is that when computing a shorter SHAKE hash value, the
> value is not a prefix of the result of computing the longer hash.
>
> I did not think this was the case -- the sponge construction seems to only
use
> the 'd' parameter to truncate the output stream, but 'd' does not seem to
> otherwise cause the output stream to vary. Indeed, Section
> 4 of FIPS-202 concludes:
>
> % Note that the input d determines the number of bits that Algorithm 8 %
> returns, but it does not affect their values.
>
> Am I misunderstanding what the quoted statement is trying to convey?
[JLS] This was a conflict between what I "knew to be true", even though I
had read the opposite several times, and what is "really true". I kept
forgetting this because of the fact that I knew there was no need for HMAC
to be used because the length extension attack did not exist.
I have chosen to restrict to two items with fixed lengths. There was
discussion on the mailing list about using a form with a length prefixed as
that variant would provide the desired behavior of changing the output for
every different length. In the end I decided that this was not a good way
to go because I expect things such as certificate databases to be indexed by
the hash value and I would not expect that the modified version of the hash
function that was suggested would be the same as the version used for that
index. The fact that this value may be computed externally and included
from that source leads me to decide that that would not currently be wise.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Section 1
>
> [CMS]. 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. Additionally, an
> application is going to be better off defining this type of structure
> so that it can include any additional data that needs to be hashed,
> as well as methods of obtaining the data.
>
> (The "additionally" bits were also part of the original intentional
omission's
> justification. I don't know that we need to make this clear specifically,
though.)
[JLS] I think the next paragraph flows out of the "additionally" bits. I
think it is better to keep it. For me this reads as an additional reason
for the omission, but I agree that I don't think this needs to be clearer.
>
> signature to be validated without first downloading all of the
> content associated with the signature. This capability can be of
> even greater importance in a constrained environment as not all of
> the content signed may be needed by the device.
>
> nit (I think this came up in Warren's comments, too?): we should clarify
that
> this functionality is used when the content being signed is broken up into
> multiple chunks, each of which is represented as a hash
> value+hash algorithm -- for any individual signature output or hash
> value, the full plaintext must be processed, but the chunks that are not
of
> interested do not need to be fetched+hashed -- only their contribution to
the
> signature is processed.
[JLS]
I have changed the paragraph to read
Indirect signing of content is a paradigm where the content is not
directly signed, but instead a hash of the content is computed and that hash
value, along with an identifier for the hash algorithm, is included in the
content that will be signed.
Doing indirect signing allows for a signature to be validated
without first downloading all of the content associated with the signature.
Rather the signature can be validated on all of the hash values and
pointers to the associated contents, then those associated parts can be
downloaded, the hash value of that part computed, and then compared to the
hash value in the signed content.
This capability can be of even greater importance in a constrained
environment as not all of the content signed may be needed by the device.
An example of how this is used can be found in <xref
target="I-D.ietf-suit-manifest"/>.
The third and last sentences are new. The third sentence provides a script
for how validation would be done and the last sentence points to a place
where this is being done.
>
> common. One of the primary things that has been identified by a hash
> function for secure message is a certificate. Two examples of this
>
> nit: the grammar doesn't look right; maybe "messages" plural?
[JLS] s/for secure/in a secure/
>
> Section 2
>
> signature or using the hash as part of the body to be signed. Other
> uses of hash functions do not require the same level of strength.
>
> This sounds like it's definitively saying that all other uses do not
require this
> strength, which doesn't seem right. Maybe "may not require"?
[JLS] Done.
>
> them. 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.
>
> BCP 201 would be a great reference here :)
[JLS] Yes it would.
>
> A hash function is a map from one, normally large, bit string to a
> second, usually smaller, bit string. There are going to be
> collisions by a hash function. The trick is to make sure that it is
> difficult to find two values that are going to map to the same output
>
> side note: if I was writing this (but I'm not!), I'd say something like
"because the
> output range has so many fewer possible configurations than the input
domain,
> there will inherently be many collisions where different input strings
produce
> the same output string".
[JLS] I took part of this.
>
> Section 2.1
>
> * Additional data, this can be something as simple as a random value
> to make finding hash collisions slightly harder (as the value
>
> (Do we want to use the word "salt"?)
[JLS] Yeah, I guess it should.
>
> handed to the application cannot have been selected to have a
> collision), or as complicated as a set of processing instructions
>
> I can't tell if this parenthetical is supposed to say "as long as the
[salt] value
> handed to the application[...]" or "as the data handed to the application
cannot
> have been selected to have a collision when combined with the unknown-at-
> the-time [salt] value".
[JLS] Identified as payload and switch from cannot to could have been.
>
> hashed be included. (Encoding as a CBOR array accomplished this
> requirement.)
>
> nit: s/accomplished/accomplishes/
[JLS] Fixed
>
> COSE_Hash_V = (
> 1 : int / tstr, # Algorithm identifier
> 2 : bstr, # Hash value
> 3 : tstr ?, # Location of object hashed
> 4 : any ? # object containing other details and things
> )
>
> nit: the '?' goes before the optional element, not after.
[JLS] What you think as the chair of the CBOR working group I should know
this?
>
> An alternative structure that could be used for situations where one
> is searching a group of objects for a match. In this case, the
>
> nit: sentence fragment.
[JLS] I think I cleaned it up.
>
> Section 3.1
>
> Despite the above, there are still times where SHA-1 needs to be used
> and therefore it makes sense to assign a point for the use of this
> hash algorithm. Some of these situations are with historic HSMs
>
> nit: do you have a preference among "point", "code point", and
"codepoint"?
[JLS] No -
>
> Because of the known issues for SHA-1 and the fact that is should no
>
> nit: s/is/it/
[JLS] Already fixed.
>
> Section 3.2
>
> * *SHA-256/64* provides a truncated hash. The length of the
> truncation is designed to allow for smaller transmission size.
> The trade-off is that the odds that a collision will occur
> increase proportionally. Locations that use this hash function
>
> Pedantically, "proportionally" would require some explanation (and
possibly the
> word "exponentially". I don't insist on any changes here, though.
[JLS] I think it is fine. Yes the proportion is to the exponent but I think
this does not need to be explicit.
>
> need either to analysis the potential problems with having a
>
> nit: s/analysis/analyze/
[JLS] Fixed.
>
> collision occur, or where the only function of the hash is to
> narrow the possible choices.
>
> nit: the grammar of the "or where [...]" clause doesn't match up with the
start
> of the sentence.
[JLS] I changed it and dropped a note to the RFC editor.
>
> The latter is the case for [I-D.ietf-cose-x509]. The hash value
> is used to select possible certificates and, if there are multiple
> choices then, each choice can be tested by using the public key.
>
> nit: maybe "multiple choices remaining"?
[JLS] Yes that makes sense.
>
> Section 3.3
>
> The family of SHA-3 hash algorithms [FIPS-202] was the result of a
> competition run by NIST. The pair of algorithms known as SHAKE-128
> and SHAKE-256 are the instances of SHA-3 that are currently being
> standardized in the IETF.
>
> "But what about RFC 6931?"
> (Yes, I see RFC 8692 and RFC 8702 that only do the SHAKEs.)
[JLS]
>
> Unlike the SHA-2 hash functions, no algorithm identifier is created
> for shorter lengths. Applications can specify a minimum length for
> any hash function. A validator can infer the actual length from the
> hash value in these cases.
>
> In light of my disuss point, I think this claim needs some
reconsiderations as
> well -- absent some other mechanism to detect modification (truncation),
an
> attacker could truncate a longer output to a shorter one, undetected by
the
> validator, since the one stream is a prefix of the other.
>
> |SHAKE128|TBD10|128-bit SHAKE| [] | [This | Yes |
>
> I'm not sure that we really want the description to just be "128-bit
SHAKE" --
> the 128 and 256 relate to the "capacity" of the sponge construction and
are not
> tied to the output length.
[JLS] With fixed lengths - I have changed this.
>
> Also, I think we should consider having some "minimum output length"
> that has to be used in order to qualify for the "Recommended:Yes".
[JLS] But that is now gone.
>
> Section 4.1
>
> In addition, IANA is to add the value of 'Filter Only' to the set of
> legal values for the 'Recommended' column. This value is only to be
> used for hash functions and indicates that it is not to be used for
> purposes which require collision resistance. IANA is requested to
> add this document to the reference section for this table due to this
> addition.
>
> So the ordering is now "Yes, No, Filter Only, Deprecated"?
[JLS] Yes I believe that to be true. The interesting question is when to
make those jumps. I think that generally Filter Only is almost the same as
deprecated for hash algorithms.
>
> Section 5
>
> There are probably some considerations relating to the application's
> "additional data" used in a CBOR hash structure such as the (first) one in
> Section 2.1. Making sure that all the relevant attributes/parameters are
bound
> into the computation/verification properly, etc.
[JLS] I am not sure that this is true. All of the properties are
cryptographically bound into the overall signature. So all that leaves
would be to say - Do what is there and not something else - which does not
really sound like a security consideration to me.
>
> security all need to be included as part of this analysis. In many
> cases the value being hashed is a public value, as such pre-image
> resistance is not part of this analysis.
>
> nit: comma splice.
[JLS] Think it got it.
>
> Algorithm agility needs to be considered a requirement for any use of
> hash functions. As with any cryptographic function, hash functions
>
> (BCP 201 rears its head again)
[JLS] But much easier to do a second time.
>
> Section 6
>
> It's not really going to work so great to have normative references to
both RFC
> 8152 and the thing that obsoletes RFC 8152. Given the one place that we
cite
> [COSE], moving it to informative seems reasonable.
[JLS] I agree. Done.
>
> Section 7
>
> RFC 3174, on the other hand, is needed to implement one of the hashes that
> we're allocating a codepoint for, so should probably be normative.
> (It's already on the downrefs registry, so that's not a concern.)
[JLS] Yuck - An informative reference on something we say you shouldn't do.
>
> Also, if we depend on the registry actions in 8152bis-algs, does that make
it a
> normative dependency? (8152bis-struct will be taking care of any downref
> concerns already, I think, for what it's worth.)
[JLS] I would expect that the RFC editor would remove the paragraph because
it is an instruction that does not need to be kept long term. I will so
note in the xml.
Jim
>
>
>
> _______________________________________________
> COSE mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
