Subject: Re: [COSE] alg Header Parameter

From: Ludwig Seitz <[email-masked]>
Date: Tue, 1 Sep 2015 11:36:00 +0200

On 2015-08-31 22:12, Mike Jones wrote:
> Replies inline below prefixed by Mike> …
>
[...]
>  > What about adding a timestamp field (for an alternative replay
>
>  > protection mechanism for those cases where sequences numbers are not
> appropriate)?
>
> I am very open to defining additional items that are expected to be
> commonly used.
>
> In terms of timestamps.  How do you believe that they should be
> defined?  As only positive numbers? As strings? Using the Unix time format?
>
> Mike> The timestamp is typically included in the message payload – not
> as a header parameter.  For instance, while JWT [RFC 7519] defines the
> "jti" (JWT ID) claim in
> http://tools.ietf.org/html/rfc7519#section-4.1.7, this is an optional
> part of the payload – not part of the header.  The header parameters
> should normally be just about declaring the cryptographic operations
> performed on the payload and not used as a general-purpose bag of
> additional application data, which this timestamp proposal feels like.
>
> The fact that there’s not any one clear choice for the representation of
> the timestamp provides a strong hint that this is the province of the
> application – not the crypto library.
>

Mike, I would expect the crypto-wrapper (here COSE) to provide such 
functionality as e.g. replay-protection and message freshness. Am I 
interpreting your comment correctly that you'd rather move these 
functions into the application?

Regards,

Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 1 Sep 2015 07:05:12 -0700

> -----Original Message-----
> From: COSE [mailto:[email-masked]] On Behalf Of Ludwig Seitz
> Sent: Tuesday, September 01, 2015 2:36 AM
> To: [email-masked]
> Subject: Re: [COSE] alg Header Parameter
> 
> >  > protection mechanism for those cases where sequences numbers are
> > not appropriate)?
> >
> > The fact that there’s not any one clear choice for the representation
> > of the timestamp provides a strong hint that this is the province of
> > the application – not the crypto library.
> >
> 
interpreting
> your comment correctly that you'd rather move these functions into the
> application?

A big part of the question is what the meaning of the timestamp is.  The
timestamp can be related to when the content was created or when the content
was either signed or encrypted.  Timestamps can also be related to when
content expires.  If the timestamp is about the content, then it makes sense
to have as part of the content.  If the timestamp is about the signature or
encryption then it makes sense to have it at that layer. 

Where do you expect the replay-protection and/or freshness to be checked?
These may be fields that are contained, for example, in the CoAP wrapper and
just authenticated by the cryptography.  Part of the question of defining
fields is deciding on semantics for those fields as well.

Jim

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 5 Sep 2015 13:52:44 +0200

Hi Jim,

On 08/31/2015 07:26 PM, Jim Schaad wrote:
> You have a much different view of key ids than what I do.  I do not
> believe that key ids are unique so I very leery of the idea that
> everything necessary can be determined from the key id.
> Additionally, while it may be true in your context that algorithm can
> be determined from the key id, this is not going to be true in all
> contexts and potentially for all key ids.

I am wondering what use cases you have in mind.

At the moment, I am looking at the application layer version of the DTLS
multicast to figure out whether that's the application layer solution
using COSE makes some sense.

Then, I also want to use COSE/CBOR as a way to encode access tokens.
Here is the description we have in mind:
https://tools.ietf.org/html/draft-somaraju-ace-multicast-00

We are also looking into a COSE/CBOR-based version of
http://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-01
Instead of HTTP the solution would apply to CoAP.

All these use cases assume prior establishment of a security context and
need an identifier to identify that context.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 5 Sep 2015 14:13:13 +0200

Hi Mike,

On 08/31/2015 10:12 PM, Mike Jones wrote:
> Mike> I am also strongly against making “alg” optional, as Key IDs need
> not be unique.  Declaring the algorithm and restricting the recipient to
> using only that algorithm is key to some of the security guarantees
> provided by COSE.

I am not sure whether this is a question about being "strongly for" or
"strongly against" making certain fields optional or mandatory.

The question is about the use cases we are trying to develop this stuff
for.

When we look back a few months on how this started then the argument as
that we cannot use JOSE because it does not work well for the Internet
of Things environment. Hence, we have to optimize.

Now with the formation of COSE we are on the optimization track and we
have to think about what use cases this should work particularly well.

I shared the use cases, which are motivated by projects I am working on
with some ARM partners (and some of the folks are on this list).

You may not care about our use cases but tell me what problems you are
trying to solve that prevent us from having the alg parameter optional.

Ciao
Hannes

---

From: Somaraju Abhinav <[email-masked]>
Date: Mon, 7 Sep 2015 07:52:29 +0000

Hi Mike,
I echo the views of Hannes here.

Mike> I am also strongly against making “alg” optional, as Key IDs need not be unique.  Declaring the algorithm and restricting the recipient to using only that algorithm is key to some of the security guarantees provided by COSE.

Could you please explain this statement a bit further maybe with your usecase. It is not clear to me what security guarantees you are referring to here.

Regards,
Abhinav

________________________________
From: COSE [[email-masked]] on behalf of Mike Jones [[email-masked]]
Sent: Monday, August 31, 2015 10:12 PM
To: Jim Schaad; 'Hannes Tschofenig'; [email-masked]
Subject: Re: [COSE] alg Header Parameter

-----Original Message-----
From: COSE [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Monday, August 31, 2015 10:27 AM
To: 'Hannes Tschofenig'; [email-masked]
Subject: Re: [COSE] alg Header Parameter

> From: COSE [mailto:[email-masked]] On Behalf Of Hannes

> Tschofenig

> Sent: Monday, August 31, 2015 12:12 AM

> To: [email-masked]<mailto:[email-masked]>

> Subject: [COSE] alg Header Parameter

> Hi Jim, Hi Brian,

> Is it possible to make the alg parameter optional?

> Reason: When a key id is used then all the necessary information,

> including the algorithm, can be determined from the key id itself.

You have a much different view of key ids than what I do.  I do not believe that key ids are unique so I very leery of the idea that everything necessary can be determined from the key id.  Additionally, while it may be true in your context that algorithm can be determined from the key id, this is not going to be true in all contexts and potentially for all key ids.

Also, my implementation does not manage the keys and therefore would not have access to the required information easily.  While it make sense to move keys into recipient structures, adding all of the other information would be a requirement of the application.

Mike> I am also strongly against making “alg” optional, as Key IDs need not be unique.  Declaring the algorithm and restricting the recipient to using only that algorithm is key to some of the security guarantees provided by COSE.

> Table 1 ' Common Header Parameters' defines the alg parameter as follows:

>    +----------+-------+----------+-----------------+-------------------+

>    | name     | label | value    | value registry  | description       |

>    |          |       | type     |                 |                   |

>    +----------+-------+----------+-----------------+-------------------+

>    | alg      | 1     | int /    | COSE Algorithm  | Integers are      |

>    |          |       | tstr     | Registry        | taken from table  |

>    |          |       |          |                 | --POINT TO        |

>    |          |       |          |                 | REGISTRY--        |

> I would prefer to only have one option to represent the value, namely

> as an integer.

Mike> Custom algorithms are likely to be best represented as strings, at least during early deployment.  Once they’re in widespread use, integers can be assigned via the registry.

> I also think that you could include a pointer to the appropriate

> section. While the other text in this section points to Section 15.3 I

> don't believe that this is actually correct.

No it was wrong - it should have been a pointer to 15.4, my anchor names were too close together.

> Regarding the fields in the header parameter table I was wondering why

> not to standardize the full list as listed in the table. Currently, a

> number of entries are marked with a "*".

These are all items which I personally am not ready to say are going to make the final cut in the document.   Thus item 1 in the Open issues section below the table.

> Regarding the nonce field do you expect it to also serve as a

> container for sequence numbers or do you plan to add a separate field for it?

My initial idea was that it would be able to hold sequence numbers, however I am no longer sure that I think that is correct.

> protection mechanism for those cases where sequences numbers are not appropriate)?

I am very open to defining additional items that are expected to be commonly used.

In terms of timestamps.  How do you believe that they should be defined?  As only positive numbers? As strings? Using the Unix time format?

Mike> The timestamp is typically included in the message payload – not as a header parameter.  For instance, while JWT [RFC 7519] defines the "jti" (JWT ID) claim in http://tools.ietf.org/html/rfc7519#section-4.1.7, this is an optional part of the payload – not part of the header.  The header parameters should normally be just about declaring the cryptographic operations performed on the payload and not used as a general-purpose bag of additional application data, which this timestamp proposal feels like.

The fact that there’s not any one clear choice for the representation of the timestamp provides a strong hint that this is the province of the application – not the crypto library.

Jim

> Hannes

_______________________________________________

COSE mailing list

[email-masked]<mailto:[email-masked]>

https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fcose&data=01%7c01%7cMichael.Jones%40microsoft.com%7c04359d5c50104e8bf5c408d2b229b3cd%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ry%2fmKA939D2PsC8xJBTRb%2fRMvkWmELwU07VCoBbHGb8%3d

________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.

---

From: Sandeep Kumar <[email-masked]>
Date: Wed, 9 Sep 2015 09:48:12 +0200

Hi Mike

I think we are talking past each other with different use cases. Many IoT
devices will be configured once with their key/alg combinations and it does
not matter what the message says. As a good security practice I will not
use my pre-configured key with some other alg mentioned in the message
making it a completely optional field to send in the first place.

regards
Sandeep

On Mon, Sep 7, 2015 at 9:52 AM, Somaraju Abhinav <
[email-masked]> wrote:

> Could you please explain this statement a bit further maybe with your
> usecase. It is not clear to me what security guarantees you are referring
> to here.
>
> Regards,
> Abhinav
>
> ------------------------------
> *From:* COSE [[email-masked]] on behalf of Mike Jones [
> [email-masked]]
> *Sent:* Monday, August 31, 2015 10:12 PM
> *To:* Jim Schaad; 'Hannes Tschofenig'; [email-masked]
>
> *Subject:* Re: [COSE] alg Header Parameter
>
> > From: COSE [mailto:[email-masked] <[email-masked]>] On
> Behalf Of Hannes
>
> > Tschofenig
>
> believe that key ids are unique so I very leery of the idea that everything
> necessary can be determined from the key id.  Additionally, while it may be
> true in your context that algorithm can be determined from the key id, this
> is not going to be true in all contexts and potentially for all key ids.
>
>
>
> Also, my implementation does not manage the keys and therefore would not
> have access to the required information easily.  While it make sense to
> move keys into recipient structures, adding all of the other information
> would be a requirement of the application.
>
>
>
> Mike> Custom algorithms are likely to be best represented as strings, at
> least during early deployment.  Once they’re in widespread use, integers
> can be assigned via the registry.
>
>
>
> These are all items which I personally am not ready to say are going to
> make the final cut in the document.   Thus item 1 in the Open issues
> section below the table.
>
>
>
> >
>
> My initial idea was that it would be able to hold sequence numbers,
> however I am no longer sure that I think that is correct.
>
>
>
> >
>
> In terms of timestamps.  How do you believe that they should be defined?
> As only positive numbers? As strings? Using the Unix time format?
>
>
>
> Mike> The timestamp is typically included in the message payload – not as
> a header parameter.  For instance, while JWT [RFC 7519] defines the "jti"
> (JWT ID) claim in http://tools.ietf.org/html/rfc7519#section-4.1.7, this
> is an optional part of the payload – not part of the header.  The header
> parameters should normally be just about declaring the cryptographic
> operations performed on the payload and not used as a general-purpose bag
> of additional application data, which this timestamp proposal feels like.
>
>
>
> [email-masked]
> ________________________________________________________ The contents of
> this e-mail and any attachments are confidential to the intended recipient.
> They may not be disclosed to or used by or copied in any way by anyone
> other than the intended recipient. If this e-mail is received in error,
> please immediately notify the sender and delete the e-mail and attached
> documents. Please note that neither the sender nor the sender's company
> accept any responsibility for viruses and it is your responsibility to scan
> or otherwise check this e-mail and any attachments.
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose
>
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 9 Sep 2015 15:15:18 +0000

What concerns me about the usage pattern you describe is that there’s no provision for crypto agility.  One of the reasons for always carrying the algorithm identifier is that then there’s no built-in assumptions that the algorithm is constant and will never change.  That’s not a practice that I believe that an IETF crypto specification should support or encourage.

                                                            -- Mike

From: Sandeep Kumar [mailto:[email-masked]]
Sent: Wednesday, September 09, 2015 12:48 AM
To: Somaraju Abhinav
Cc: Mike Jones; Jim Schaad; Hannes Tschofenig; [email-masked]
Subject: Re: [COSE] alg Header Parameter

Hi Mike
I think we are talking past each other with different use cases. Many IoT devices will be configured once with their key/alg combinations and it does not matter what the message says. As a good security practice I will not use my pre-configured key with some other alg mentioned in the message making it a completely optional field to send in the first place.
regards
Sandeep

On Mon, Sep 7, 2015 at 9:52 AM, Somaraju Abhinav <[email-masked]<mailto:[email-masked]>> wrote:
Hi Mike,
I echo the views of Hannes here.

Regards,
Abhinav

________________________________
From: COSE [[email-masked]<mailto:[email-masked]>] on behalf of Mike Jones [[email-masked]<mailto:[email-masked]>]
Sent: Monday, August 31, 2015 10:12 PM
To: Jim Schaad; 'Hannes Tschofenig'; [email-masked]<mailto:[email-masked]>

-----Original Message-----
From: COSE [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jim Schaad
Sent: Monday, August 31, 2015 10:27 AM
To: 'Hannes Tschofenig'; [email-masked]<mailto:[email-masked]>
Subject: Re: [COSE] alg Header Parameter

Mike> The timestamp is typically included in the message payload – not as a header parameter.  For instance, while JWT [RFC 7519] defines the "jti" (JWT ID) claim in http://tools.ietf.org/html/rfc7519#section-4.1.7<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2frfc7519%23section-4.1.7&data=01%7c01%7cMichael.Jones%40microsoft.com%7cbc084841200a4af9335008d2b8eb050a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=s2lFARUO4IfYMbQMr1l20RDNXzbHtGt7rbM0Y8yeOtk%3d>, this is an optional part of the payload – not part of the header.  The header parameters should normally be just about declaring the cryptographic operations performed on the payload and not used as a general-purpose bag of additional application data, which this timestamp proposal feels like.

Jim

COSE mailing list

_______________________________________________
COSE mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cose<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fcose&data=01%7c01%7cMichael.Jones%40microsoft.com%7cbc084841200a4af9335008d2b8eb050a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=CjdJwkAhGEYGQ7f2R1YDogl3LvF%2bx43%2f4SJAKlN4RK0%3d>

---

From: Somaraju Abhinav <[email-masked]>
Date: Thu, 10 Sep 2015 06:13:10 +0000

Hi Mike,
The configuration of the constrained devices with key and alg need not be a one time thing. Crypto agility is still possible at configuration time. Most of these devices will probably only come with a very limited cipher suite anyways.
Abhinav

Sent from my Windows Phone
________________________________
From: Mike Jones<mailto:[email-masked]>
Sent: ‎09/‎09/‎2015 17:15
To: Sandeep Kumar<mailto:[email-masked]>; Somaraju Abhinav<mailto:[email-masked]>
Cc: Jim Schaad<mailto:[email-masked]>; Hannes Tschofenig<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [COSE] alg Header Parameter

                                                            -- Mike

Hi Mike

Regards,
Abhinav

-----Original Message-----
From: COSE [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jim Schaad
Sent: Monday, August 31, 2015 10:27 AM
To: 'Hannes Tschofenig'; [email-masked]<mailto:[email-masked]>
Subject: Re: [COSE] alg Header Parameter

Jim

COSE mailing list

---

From: Somaraju Abhinav <[email-masked]>
Date: Fri, 11 Sep 2015 08:42:29 +0000

Mike> I am also strongly against making "alg" optional, as Key IDs need not be unique.  Declaring the algorithm and restricting the recipient to using only that algorithm is key to some of the security guarantees provided by COSE.

Could you please explain this further. It is not clear to me what security guarantees you are referring to. In particular, if we can assume that the alg can be determined from the context of the message (e.g. from CoAP headers).

From: COSE [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Montag, 31. August 2015 22:13
To: Jim Schaad; 'Hannes Tschofenig'; [email-masked]
Subject: Re: [COSE] alg Header Parameter

Replies inline below prefixed by Mike> ...

-----Original Message-----
From: COSE [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Monday, August 31, 2015 10:27 AM
To: 'Hannes Tschofenig'; [email-masked]<mailto:[email-masked]>
Subject: Re: [COSE] alg Header Parameter

Mike> I am also strongly against making "alg" optional, as Key IDs need not be unique.  Declaring the algorithm and restricting the recipient to using only that algorithm is key to some of the security guarantees provided by COSE.

> as an integer.

Mike> Custom algorithms are likely to be best represented as strings, at least during early deployment.  Once they're in widespread use, integers can be assigned via the registry.

Mike> The timestamp is typically included in the message payload - not as a header parameter.  For instance, while JWT [RFC 7519] defines the "jti" (JWT ID) claim in http://tools.ietf.org/html/rfc7519#section-4.1.7, this is an optional part of the payload - not part of the header.  The header parameters should normally be just about declaring the cryptographic operations performed on the payload and not used as a general-purpose bag of additional application data, which this timestamp proposal feels like.

The fact that there's not any one clear choice for the representation of the timestamp provides a strong hint that this is the province of the application - not the crypto library.

Jim

COSE mailing list