On Mon, Jul 06, 2020 at 12:15:11PM -0700, Jim Schaad wrote:
>
>
> > -----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
Okay.
We should actually remove the "One of the benefits of this difference is
that when computing a shorter SHAKE hash value, the value is not a prefix
of the result of computing the longer hash" language, though.
Also, per Ilaari's remarks it sounds like we're doing to be lengthening the
lengths, too.
> 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.
It seems like that same argument ("might not be the same as the one used
for the index") could be applied to basically any SHAKE formulation we use,
though. That said, Ilari's proposal is fairly natural, at least.
> >
> >
> > ----------------------------------------------------------------------
> > 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.
Right, I think it's an additional reason for the omission, but the
transition between sentences does not make this super-super-obvious.
There's the simple option "An additional reason for the omission is that an
application [...]", but you can decide whether that's too banal to put in.
> >
> > 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.
I think that clarifies things enough, thanks.
> >
> > 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?
Nah, the authors will take care of it. :)
> >
> > 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.
Sure.
> >
> > 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.
That's my sense, too.
> >
> > 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.
What overall signature? Can't we use hashes outside of a signature?
Sure, if there's a containing signature, that takes care of getting the
parameters bound to the hash calculation, but if there's no signature we
probably want some other way of doing that.
> >
> > 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.
I'm just going by
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
> >
> > 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.
Ah, fair enough.
Thanks for the updates!
-Ben
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
