Re: [COSE] Comments for draft-ietf-cose-msg-03

["Jim Schaad" <[e-mail]>]

> -----Original Message-----
> From: COSE [mailto:[e-mail]] On Behalf Of Hannes Tschofenig
> Sent: Thursday, August 27, 2015 9:23 AM
> To: [e-mail]
> Subject: [COSE] Comments for draft-ietf-cose-msg-03
> 
> Hi Jim, Hi all,
> 
> out of curiosity I have been reading through the latest version of the COSE draft
> and ran into a few questions.

You might also look at the WIP draft on github as it has a change from using maps to arrays at the top level.  This makes the code slightly different and provides a small decrease in message sizes.

> 
> * MTI
> 
> Section 1.6 is supposed to define mandatory-to-implement algorithms but
> actually doesn't say what those are.
> 
> I personally don't believe it is useful to define MTI algorithms for such a
> document that will most likely be used in a variety of different environments. I
> would nevertheless be interested to know what the MTI algorithms should be
> (from your point of view).

I agree with the idea of it not being useful to define the MTI algorithms.  I am at a loss why you think it should be given that the first paragraph includes the following sentence:

However, we have elected not to specify a set of mandatory algorithms in this document.

That being said.  If I were to think about a mandatory set it would probably look something like:

* Content Encryption: either AES-GCM or AES-CCM depending on if you think that small devices are the target market.  AES-CCM is easier to implement, but it prohibits any streaming encryption operation as you need to know the length of the output before you start.
* Key Management: Probably ECDH either directly or wrapped with AES-KW.  The first allows for low grade origination if one does static-static so it would be useful both for encryption and MACs
* MAC algorithm - HMAC-Sha256
* Signature Algorithm - ECDSA

The latter three make the assumption that SHA-256 is a supported hash algorithm.  If that is not doable then one would need to re-look at the outputs.  I am not ready to jump ship to the new algorithms, but might soon be willing to do so with the new ECDH curve and signatures.

> 
> * Examples
> 
> As most people I also look at the examples first and would have appreciated a
> bit more explanation. So, help me understand them.
> 
> Take Appendix C.1.1 "Shared Secret Direct MAC". I assume that the 'direct
> shared secret' means that the sender of the message and the receiver share a
> symmetric key.

Yes this is correct.

> 
> What does "File name: Mac-04" mean?

This is the name of the file in the examples project up on github (see first paragraph of appendix C).

> 
> Just to make sure that I understand the structure correctly I added comments
> inline:
> 
>    {
>      1: 3,  --> msg_type is COSE_mac
>      2: h'a1016f4145532d434d41432d3235362f3634',
> 
>    --> protected header fields
>     When I use a CBOR decoder I get the value of '"\xA1\x01oAES-CMAC-256/64".
>     Is that really the encoding for the algorithm id?

Yes.  The string will be shortened to an integer when it gets assigned.  Until then I am using the string for the identifier.  At that point it would be something like 'a101XX'  where XX would be an encoded integer of the correct value.  This is expected to be done relatively soon.

> 
>      4: h'546869732069732074686520636f6e74656e742e',
>      --> payload of the string "This is the content."
> 
>      10: h'd9afa663dd740848', --> tag which contains the MAC value.
>      9: [ --> recipients
>        {
>          3: {
>            1: -6,
>            4: h'6f75722d736563726574'
>          }
>        }
>      ]
>    }
> 
> Section 6 talks about recipients and says:
> 
> "
>    recipients  contains the recipient information.  See the description
>       under COSE_Encryption for more info.
> "
> 
> When I look for more info in Section 5 then I do not find a lot.
> Why is the field mandatory? What is the meaning of it in this example?

For MACs, one still needs to do some type management for the recipient to identify the key that is going to be used to compute the MAC for verification.  This is not restricted to just having a pre-shared secret.  Instead one can derive the secret by using, for example, ECDH-SS.  Part of the question here is if anonymous MAC is interesting (i.e. just encrypting the MAC key for the recipient with RSA) or if low grade origination is needed.  Even for low-grade origination the direct, derived from direct and ECDH-SS direct recipient types would all give the needed origination proofs.

> 
> For an IoT context I would imagine that the algorithm and the key has been
> agreed between the sender and the receiver using some key management
> protocol and the appropriate example would be something like:
> 
>    {
>      1: 3,
>      2: {4: 1,6: 1},
>      4: "This is the content.",
>      10: h'd9afa663dd740848'
>    }
> 
> (Note that I don't really know whether this is the encoding you envision for the
> header parameters.)

There is an on-again, off-again discussion about making direct key management privileged in terms of key management.  Personally, I am against this as I would prefer to see everything be uniform in all cases and I don't know that you win enough by making things special.  Part of the question is are you ever going to do anything except direct key.   >From a security point of view, I would argue that you are much better off doing a KDF on a shared secret and using that on a per message basis rather than having a key that is used until some external event occurs.  

I would also tend to make the same argument about making the algorithm be implicit rather than explicit.  While possible, I don't know that this is really a good idea.  I have generally found it to be a problem latter on in the process.  However, the implementations that I have done would allow for that to happen.  I just don't care for it as a suggested way to travel.

This means that I would be looking more at
{  1:3,
   2:{1:15},
   4:"This is the content.",
   10:h'd9afa663dd740848',
   9:[{ 3:{1:-6}}]
}

I am not sure what you are looking at for the two parameters that you included in your example.  If they are just place holders then you could include them as well.  I omit the KID parameter from the recipient structure since that can be implied relatively easily if you only have one dialog going on between the two entities.  If you have multiple dialogs then include a KID is useful.

> 
> Minor issues:
> 
> * You write: "CBOR extended the data model of the JavaScript Object Notation
> (JSON) by allowing for binary data among other changes."
> 
> Is 'data model' the right term here? I think we are talking about encoding.
> For a more detailed treatment of what a data model is take a look at RFC 3444.

I took the term from RFC 7049 in the introduction section.  Different people have different definitions of data model but I think that this is a legal one.

"The underlying data model is an extended version of the JSON data model [RFC4627]."

> 
> * You write:
> "
>    o  The author did not always agree with some of the decisions made by
>       the JOSE working group.  Many of these decisions have been re-
>       examined, and where it seems to the author to be superior or
>       simpler, replaced.
> "
> 
> For a working group draft it does not matter whether the author agrees or
> disagrees. I would suggest to remove this paragraph.

Yes - It was originally written to be an individual draft not a working group draft.  I will look at doing a re-write because for people who come into this from the JOSE world, they may want some explanation about why things are different.

> 
> 
> * SMIME/CMS
> 
> I would remove references to CMS and S/MIME since they are most likely only
> helpful to a very small audience.

Will look at.

> 
> Ciao
> Hannes
>