Subject: Re: [COSE] Call for Consensus: Standalone Hash Algorithms Document

From: Jim Schaad <[email-masked]>
Date: Fri, 1 Mar 2019 11:01:25 -0800

After sleeping on this I want to change what I said slightly.

COSE does not support the same type of structure as the ASN.1
AlgorithmIdentifier where the algorithm identifier and a set of parameters
are combined together into a single encodable entity.  Instead parameters
for algorithms are defined and placed into a COSE structure either as
protected, unprotected or implicit attributes.  Since the general structure
I have been telling people to use an array with an algorithm identifier and
the hash value with additional elements dealing with thing like how do you
find it and other sorts of things.

Thus we could indeed define equivalent to the -len version by creating an
algorithm parameter.  The question would be should we define some type of
COSE structure which is similar to AlgorithmIdentifier so that it can be
referenced and used in those cases where parameters should be included with
the algorithm number/string is placed.

Jim

From: COSE <[email-masked]> On Behalf Of Jim Schaad
Sent: Thursday, February 28, 2019 5:13 PM
To: 'Russ Housley' <[email-masked]>
Cc: 'cose' <[email-masked]>
Subject: Re: [COSE] Call for Consensus: Standalone Hash Algorithms Document

COSE does not support parameters so the later two cannot be supported by
themselves.  Rather a new code point would be assigned for a fixed parameter
set.  Thus we would need to decide what lengths should be supported for the
latter two options.

Jim

From: Russ Housley <[email-masked] <mailto:[email-masked]> > 
Sent: Thursday, February 28, 2019 4:48 PM
To: Jim Schaad <[email-masked] <mailto:[email-masked]> >
Cc: cose <[email-masked] <mailto:[email-masked]> >
Subject: Re: [COSE] Call for Consensus: Standalone Hash Algorithms Document

Jim:

Four object identifiers for SHAKE128 and SHAKE256 hash functions are defined
by NIST [1]:

     id-shake128

     id-shake256

     id-shake128-len

     id-shake256-len

The first two have no parameters, and the second two have an output length
parameter.

These are the ones that should probably be included in a COSE-friendly
manner.

Russ

[1]
https://csrc.nist.gov/Projects/Computer-Security-Objects-Register/Algorithm-
Registration

On Feb 27, 2019, at 9:09 PM, Jim Schaad <[email-masked]
<mailto:[email-masked]> > wrote:

I have much less of a problem with just doing the hashes.

So which SHAKE hashes do you think we should be defining?  To match SHA-2 it
would be SHAKE-128/64, SHAKE-128 and SHA-256. 

I don't know if there is a similar change in processing if you look at the
difference between 32 and 64 bit processors which can be found with the
SHA-2 implementations.  This lead to putting in the SHA-512/256 registration
that I put in the current draft.

Jim

-----Original Message-----
From: Russ Housley <[email-masked] <mailto:[email-masked]> >
Sent: Wednesday, February 27, 2019 12:54 PM
To: Jim Schaad <[email-masked] <mailto:[email-masked]> >
Cc: cose <[email-masked] <mailto:[email-masked]> >
Subject: Re: [COSE] Call for Consensus: Standalone Hash Algorithms
Document

Jim:

I as suggesting that SHAKE be added as a hash function.  Sure, it might be
added to other documents as well, but I was not suggesting that.

Russ

On Feb 27, 2019, at 3:44 PM, Jim Schaad <[email-masked]
<mailto:[email-masked]> > wrote:

I am not sure that I completely agree with that.

First adding SHAKE other than as a hash function would mean that this
is not a standalone hash algorithm document.  Second, I am not sure at
this point of all of the different varieties and locations where SHAKE

should

be added.

Hash Functions:  Do we have just the two versions or do we have a
truncated 64-bit version as well.  Not sure about where the variant
that had a small b would fall in here, but for now it might just be

ignored.

Signature Algorithms:  At this point I don't know if there would need
to be any RSA versions or not.  Not sure what to say about DH
versions.  ECDSA maybe makes some sense.

Message Authentication Algorithms:  Do we put in a KMAC here or not?

Key Derivation Functions:  Do we just do HMAC with a KMAC drop in here
or does NIST have a different recommended way to do KDF with SHAKE

functions?

We should definitely be able to get rid of HMAC when doing this as
SHAKE already has length extension attacks solved.

Key Agreement Functions: Since you need to have a combined key
agreement algorithm and KDF for COSE, how many of these are we going

to define.

Encryption and Key Wrap algorithms:  I sorta hope that this can be
avoided for now, but I know that there are some AEAD algorithms which
are built using Keccak as an underlying primitive and I am not
personally ready to try and figure out how it works, but it is
something that might need to be discussed here (and in CFRG).

Given that the object is to get the hash algorithm assignments done
for the SUIT developers, I am not sure that doing this work in this
document makes sense.  I will also note that the CMS work in LAMPS and
CURDLE ignored the issues of new KDFs w/ SHAKE entirely so that maybe

groundbreaking work here.

Jim

-----Original Message-----
From: Russ Housley <[email-masked] <mailto:[email-masked]> >
Sent: Tuesday, February 26, 2019 7:04 AM
To: Jim Schaad <[email-masked] <mailto:[email-masked]> >
Cc: cose <[email-masked] <mailto:[email-masked]> >
Subject: Re: [COSE] Call for Consensus: Standalone Hash Algorithms
Document

Jim:

It would probably be easy to add SHAKE now.  The equivalent document
for CMS is draft-ietf-lamps-cms-shakes.

Russ

On Feb 25, 2019, at 7:38 PM, Jim Schaad <[email-masked]
<mailto:[email-masked]> >

wrote:

A version of what this document would look like can be found here
https://tools.ietf.org/html/draft-schaad-cose-hash-algs-01

Jim

-----Original Message-----
From: COSE <[email-masked] <mailto:[email-masked]> > On Behalf
Of Matthew A. Miller
Sent: Monday, February 25, 2019 4:16 PM
To: cose <[email-masked] <mailto:[email-masked]> >
Subject: [COSE] Call for Consensus: Standalone Hash Algorithms
Document

This messages starts a call for consensus to separate the COSE hash
algorithms into a separate document, ending on 2018-03-10.

In the virtual interim on 02-15, it was proposed to separate them
from draft- ietf-cose-x509, to allow the hash algorithm
registrations to stabilize more quickly than the rest of the X.509
draft.  If the working group agrees with separating the algorithms,
then a document will be published that consists of Section 4 (Hash
Algorithm
Identifiers) and Section 5.3 (COSE Algorithm
Registry) from draft-ietf-cose-x509.

Please respond with whether or not you support separating the hash
algorithms into a separate document.  If you do not support this,
please indicate why not.

- Ivaylo and Matthew
COSE Chairs

_______________________________________________
COSE mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/cose

_______________________________________________
COSE mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/cose

---

From: Russ Housley <[email-masked]>
Date: Fri, 1 Mar 2019 15:02:01 -0500

For now, it is probably fine to define SHAKE128 and SHAKE256 hash functions, and then deal with the -len ones when there is a need for them.

Russ

> On Mar 1, 2019, at 2:01 PM, Jim Schaad <[email-masked]> wrote:
> 
> COSE does not support the same type of structure as the ASN.1 AlgorithmIdentifier where the algorithm identifier and a set of parameters are combined together into a single encodable entity.  Instead parameters for algorithms are defined and placed into a COSE structure either as protected, unprotected or implicit attributes.  Since the general structure I have been telling people to use an array with an algorithm identifier and the hash value with additional elements dealing with thing like how do you find it and other sorts of things.
>  
> Thus we could indeed define equivalent to the -len version by creating an algorithm parameter.  The question would be should we define some type of COSE structure which is similar to AlgorithmIdentifier so that it can be referenced and used in those cases where parameters should be included with the algorithm number/string is placed.
>  
> Jim
>  
>  
> From: COSE <[email-masked] <mailto:[email-masked]>> On Behalf Of Jim Schaad
> To: 'Russ Housley' <[email-masked] <mailto:[email-masked]>>
> Cc: 'cose' <[email-masked] <mailto:[email-masked]>>
> COSE does not support parameters so the later two cannot be supported by themselves.  Rather a new code point would be assigned for a fixed parameter set.  Thus we would need to decide what lengths should be supported for the latter two options.
>  
> Jim
>  
>  
> From: Russ Housley <[email-masked] <mailto:[email-masked]>> 
> To: Jim Schaad <[email-masked] <mailto:[email-masked]>>
> Cc: cose <[email-masked] <mailto:[email-masked]>>
> Four object identifiers for SHAKE128 and SHAKE256 hash functions are defined by NIST [1]:
>  
>      id-shake128
>  
>      id-shake256
>  
>      id-shake128-len
>  
>      id-shake256-len
>  
> The first two have no parameters, and the second two have an output length parameter.
>  
> These are the ones that should probably be included in a COSE-friendly manner.
>  
> Russ
>  
>  
> [1] https://csrc.nist.gov/Projects/Computer-Security-Objects-Register/Algorithm-Registration <https://csrc.nist.gov/Projects/Computer-Security-Objects-Register/Algorithm-Registration>
>  
>  
> 
>> On Feb 27, 2019, at 9:09 PM, Jim Schaad <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>>> From: Russ Housley <[email-masked] <mailto:[email-masked]>>
>>> To: Jim Schaad <[email-masked] <mailto:[email-masked]>>
>>> Cc: cose <[email-masked] <mailto:[email-masked]>>
>>>> On Feb 27, 2019, at 3:44 PM, Jim Schaad <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>>> From: Russ Housley <[email-masked] <mailto:[email-masked]>>
>>>>> To: Jim Schaad <[email-masked] <mailto:[email-masked]>>
>>>>> Cc: cose <[email-masked] <mailto:[email-masked]>>
>>>>>> On Feb 25, 2019, at 7:38 PM, Jim Schaad <[email-masked] <mailto:[email-masked]>>
>>> wrote:
>>> 
>>>>>> 
>>>>>> https://tools.ietf.org/html/draft-schaad-cose-hash-algs-01 <https://tools.ietf.org/html/draft-schaad-cose-hash-algs-01>
>>>>>> 
>>>>>> Jim
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> From: COSE <[email-masked] <mailto:[email-masked]>> On Behalf Of Matthew A. Miller
>>>>>>> To: cose <[email-masked] <mailto:[email-masked]>>
>>>>>> https://www.ietf.org/mailman/listinfo/cose <https://www.ietf.org/mailman/listinfo/cose> 
>>>> 
>> 
>> 
>> https://www.ietf.org/mailman/listinfo/cose <https://www.ietf.org/mailman/listinfo/cose>
>  
> https://www.ietf.org/mailman/listinfo/cose <https://www.ietf.org/mailman/listinfo/cose>

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 2 Mar 2019 11:42:07 -0800

I’m not deeply familiar with SHAKE, but can the length of the bstr containing the SHAKE hash serve as the length parameter?

LL

> On Mar 1, 2019, at 11:01 AM, Jim Schaad <[email-masked]> wrote:
>

---

From: Jim Schaad <[email-masked]>
Date: Sat, 2 Mar 2019 12:48:50 -0800

It is my understanding that this would be a true statement.  SHAKE unlike SHA-2 does not produce the same prefix based on a different output length.  This means that one cannot just truncate the resulting hash value to produce a smaller tag.

Jim

From: Laurence Lundblade <[email-masked]> 
Sent: Saturday, March 2, 2019 11:42 AM
To: Jim Schaad <[email-masked]>
Cc: Russ Housley <[email-masked]>; cose <[email-masked]>
Subject: Re: [COSE] Call for Consensus: Standalone Hash Algorithms Document

LL

On Mar 1, 2019, at 11:01 AM, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

Jim

From: COSE < <mailto:[email-masked]> [email-masked]> On Behalf Of Jim Schaad
Sent: Thursday, February 28, 2019 5:13 PM
To: 'Russ Housley' < <mailto:[email-masked]> [email-masked]>
Cc: 'cose' < <mailto:[email-masked]> [email-masked]>
Subject: Re: [COSE] Call for Consensus: Standalone Hash Algorithms Document

Jim

From: Russ Housley < <mailto:[email-masked]> [email-masked]> 
Sent: Thursday, February 28, 2019 4:48 PM
To: Jim Schaad < <mailto:[email-masked]> [email-masked]>
Cc: cose < <mailto:[email-masked]> [email-masked]>
Subject: Re: [COSE] Call for Consensus: Standalone Hash Algorithms Document

Jim:

     id-shake128

     id-shake256

     id-shake128-len

     id-shake256-len

Russ

[1]  <https://csrc.nist.gov/Projects/Computer-Security-Objects-Register/Algorithm-Registration> https://csrc.nist.gov/Projects/Computer-Security-Objects-Register/Algorithm-Registration

On Feb 27, 2019, at 9:09 PM, Jim Schaad < <mailto:[email-masked]> [email-masked]> wrote:

Jim

-----Original Message-----
From: Russ Housley < <mailto:[email-masked]> [email-masked]>
Sent: Wednesday, February 27, 2019 12:54 PM
To: Jim Schaad < <mailto:[email-masked]> [email-masked]>
Cc: cose < <mailto:[email-masked]> [email-masked]>
Subject: Re: [COSE] Call for Consensus: Standalone Hash Algorithms
Document

Jim:

Russ

On Feb 27, 2019, at 3:44 PM, Jim Schaad < <mailto:[email-masked]> [email-masked]> wrote:

should

be added.

ignored.

functions?

to define.

Jim

-----Original Message-----
From: Russ Housley < <mailto:[email-masked]> [email-masked]>
Sent: Tuesday, February 26, 2019 7:04 AM
To: Jim Schaad < <mailto:[email-masked]> [email-masked]>
Cc: cose < <mailto:[email-masked]> [email-masked]>
Subject: Re: [COSE] Call for Consensus: Standalone Hash Algorithms
Document

Jim:

Russ

On Feb 25, 2019, at 7:38 PM, Jim Schaad < <mailto:[email-masked]> [email-masked]>

wrote:

A version of what this document would look like can be found here
 <https://tools.ietf.org/html/draft-schaad-cose-hash-algs-01> https://tools.ietf.org/html/draft-schaad-cose-hash-algs-01

Jim

-----Original Message-----
From: COSE < <mailto:[email-masked]> [email-masked]> On Behalf Of Matthew A. Miller
Sent: Monday, February 25, 2019 4:16 PM
To: cose < <mailto:[email-masked]> [email-masked]>
Subject: [COSE] Call for Consensus: Standalone Hash Algorithms
Document

- Ivaylo and Matthew
COSE Chairs

_______________________________________________
COSE mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/cose> https://www.ietf.org/mailman/listinfo/cose

_______________________________________________
COSE mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/cose> https://www.ietf.org/mailman/listinfo/cose

_______________________________________________
COSE mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/cose> https://www.ietf.org/mailman/listinfo/cose

---

From: Matthew Miller <[email-masked]>
Date: Sun, 10 Mar 2019 13:12:25 -0600

Thank you all that responded.  We see consensus to adopt the standalone
hash algorithms draft (embodied in
https://tools.ietf.org/html/draft-schaad-cose-hash-algs-01).

Jim, please submit draft-ietf-cose-hash-algs at your convenience.

- Ivaylo and Matthew
COSE WG Chairs

On Mon, Feb 25, 2019 at 5:15 PM Matthew A. Miller <
[email-masked]> wrote:

> In the virtual interim on 02-15, it was proposed to separate them from
> draft-ietf-cose-x509, to allow the hash algorithm registrations to
> stabilize more quickly than the rest of the X.509 draft.  If the working
> group agrees with separating the algorithms, then a document will be
> published that consists of Section 4 (Hash Algorithm Identifiers) and
> Section 5.3 (COSE Algorithm Registry) from draft-ietf-cose-x509.
>
> algorithms into a separate document.  If you do not support this, please
> indicate why not.
>
>
> - Ivaylo and Matthew
> COSE Chairs
>
>