Subject: Re: [Cose] Algorithm Questions

From: "Jim Schaad" <[email-masked]>
Date: Fri, 24 Apr 2015 05:22:21 -0700

From: Göran Selander [mailto:[email-masked]] 
Sent: Wednesday, April 22, 2015 11:48 PM
To: Jim Schaad
Cc: [email-masked]
Subject: Re: [Cose] Charter State

In order to get the CFRG pointed in the right direction, it is necessary to give it some input.   To that end I would suggest we start with doing a survey of three questions:

1.       What type of algorithms are needed?  (key agreement, key transport, signature, hash, MAC, KDF, etc)

For the use cases I have in mind: key transport, KDF, encryption/AEAD, hash and signature. But the main concern is around signatures.

1. ECDSA size of signature at 112-128 bits security is of the order of 60 bytes which is a lot compared to 8 bytes truncated MAC. It would be good to have a recommendation of a signature algorithm with message recovery, such as ECPVS (which has some IPR, some of which is expiring in a few years) or other.

So basically ECDSA, and it’s variants, have a size of 2*|r|, which comes to roughly 64 bytes for P-256.  I looked at ECPVS, and for the same level of security as the 8 byte truncated MAC I believe you are looking at |r| + 8 or 40 bytes for P-256.  It is a message size win, but I am not sure it is as big of win as you originally thought it would be.  

2. A combined symmetric key encryption + signature is needed for point-multipoint settings. 

Please explain what you mean by point-multipoint settings.  I am not familiar with that term .  (I probably know it as something else.)

2.      What are the constraints we really care about?

The charter says "Minimizing message size, code size and computational complexity”.  In order of importance for signatures I’d say message size, computational complexity, code size.

I was thinking in broader terms.  What you have listed above is more along the lines of decision criteria but not constraints.   A constraint is – We need a minimum of 64-bits of authentication tag for AEAD algorithms.  We need a minimum of X-bits for signature algorithms.  We need to have deterministic signature algorithms because our PRGNs are not good enough.  Minimal systems will only support hash and encrypt mode block ciphers.

3.      What algorithms are we currently using today for those purposes?

The default algorithms are those specified by CoAP (secp256r1 for ECDSA)

Where?  In a document that I can easily read?

Jim

From: Göran Selander [mailto:[email-masked]] 
Sent: Wednesday, April 22, 2015 12:24 PM
To: Kathleen Moriarty
Cc: Jim Schaad; [email-masked]
Subject: Re: [Cose] Charter State

Looks fine. 

About the constrained-appropriate algorithms: is the intention to consult CFRG? If so, maybe would be good to get that ball rolling too soon. 

Thanks,

Göran

On 22 apr 2015, at 18:54, Kathleen Moriarty <[email-masked]> wrote:

Great, are others ok with the changes?  If so, I'll get it rolling.

On Wed, Apr 22, 2015 at 12:41 PM, Jim Schaad <[email-masked]> wrote:

Be my guest to make the changes.

Jim

From: Cose [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Wednesday, April 22, 2015 9:27 AM
To: Jim Schaad

Cc: [email-masked]
Subject: Re: [Cose] Charter State

Hi,

I am assuming the current charter text is at the link:

https://github.com/cose-spec/wg-charter/blob/master/draft-charter.md

I have some proposed changes that I think help with readability.  Let me know if these are ok and I'll put in the charter for IESG review.  All of the charter text is included, broken out by sections to show edits.  In some cases, there is a Note: following a change with assumptions I was making in case they were not correct assumptions.

Old:Concise Binary Object Representation (CBOR, RFC 7049) is a concise binary format for the serialization of data structured to an extended version of the JSON data model. One motivation for CBOR was to make this data model more amenable to constrained nodes and constrained node networks (RFC 7228).

New:

Concise Binary Object Representation (CBOR, RFC 7049) is a concise binary format for the serialization of data structured to an extended version of the JSON data model. One motivation for COSE was to reuse functionality from the JOSE working group using the CBOR data representation as it is more amenable to constrained nodes and constrained node networks (RFC 7228).

Old:

The JOSE working group recently completed producing representations for cryptographic keys, message authentication (MACs), encryption, and digital signatures, using JSON representation. This working group will reuse the work done by JOSE, adapting it to the capabilities of CBOR. This will rely on the JOSE registries, which, where this provides additional efficiency, will be expanded with additional information.

New:

The JOSE working group recently completed producing representations for cryptographic keys, message authentication (MACs), encryption, and digital signatures, using JSON representation. COSE will rely on the JOSE registries, and will be expand them with additional information when necessary.

Note: you may have other reasons besides efficiency.

Old:

The resulting formats will not be cryptographically convertible from or to JOSE formats. This lack of a need for bit-for-bit compabitility which will enable some simplification in the adaptation process.

New: 

The resulting formats will not be cryptographically convertible from or to JOSE formats. This lack of a need for bit-for-bit compatibility will enable some simplification in the adaptation process.

Old:

Criteria that should be considered on making decisions in changing from a JSON to a CBOR encoding are:

·      Keeping the current JOSE paradigms and formatting where feasible.

·      Minimizing message size, code size and computational complexity should be considered (for the constrained environments where we expect to use this).

·      Improving security

·      Providing new functionality that uses of JOSE did not require, but are required for the new use cases.

New: 

Criteria that should be considered in the decision making process, changing from JSON to CBOR encoding include:

·      Maintain the current JOSE paradigms and formatting where feasible.

·      Minimize message size, code size, and computational complexity to suit constrained environments, where this is expected to  be used.

·      Improve security

·      Provide new functionality for additional use cases that were not required for JOSE. 

Old:

Issues dealing with key management and binding of keys to identities are out of scope for the working group.

New:

Key management and binding of keys to identities are out of scope for the working group.

Note: I am assuming you really want to out-of scope all key management and not just issues?

And I don't see any need to tweak the rest of the text:

The Working group will coordinate its progress with the ACE, DICE and CORE working groups to ensure that we are fulfilling the needs of these constituencies. Other groups may be added to this list as the set of use cases is expanded.

The WG will have two deliverables:

*	a standards-track specification covering the same cryptographic formats from JOSE, with optimizations for constrained device processing, expressed in CBOR;
*	registration for algorithms (such as AES-CCM-8) that are appropriate for constrained environments.

The Working Group will use a wiki to track desired use cases for its work, but does not intend to publish this as an RFC.

I'd love it if you can keep to the milestones projected :-)

Thanks.
Kathleen

On Tue, Apr 21, 2015 at 6:32 PM, Jim Schaad <[email-masked]> wrote:

The date change proposed by me has been merged into the draft.

I believe that we can now consider the charter discussion to be complete unless anyone else has a big issue they want to bring up.

Kathleen:  Can we get this to move forward into the IESG?

Jim

> -----Original Message-----
> From: Cose [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
> Sent: Tuesday, April 14, 2015 7:17 PM
> To: Jim Schaad
> Cc: Kepeng Li; Paul Hoffman; [email-masked]
> Subject: Re: [Cose] Charter State
>
>
>
> Sent from my iPhone
>
> > On Apr 14, 2015, at 10:10 PM, "Jim Schaad" <[email-masked]>
> wrote:
> >
> >
> >
> >> -----Original Message-----
> >> From: Cose [mailto:[email-masked]] On Behalf Of Kepeng Li
> >> Sent: Tuesday, April 14, 2015 6:59 PM
> >> To: Paul Hoffman; Jim Schaad
> >> Cc: [email-masked]
> >> Subject: Re: [Cose] Charter State
> >>
> >> Thanks Paul.
> >>
> >> There are two other changes we might want to incorporate:
> >>
> >> 1) Proposal from Goran:
> >> http://www.ietf.org/mail-archive/web/cose/current/msg00027.html
> >>
> >> OLD:
> >> "a standards-track specification covering the same cryptographic
> >> formats
> > from
> >> JOSE, expressed in CBOR"
> >>
> >> NEW:
> >> "a standards-track specification covering the same cryptographic
> >> formats
> > from
> >> JOSE and optimizations for constrained device processing, expressed
> >> in
> > CBOR
> >
> > I am agnostic about including this change.  We now are much more
> > constrained device focused later so it might not be needed.
> >
> >>
> >> (2) Proposal from Kathleen:
> >>
> >> http://www.ietf.org/mail-archive/web/cose/current/msg00077.html
> >>
> >> OLD:
> >> The Working Group will coordinate its progress with the ACE, DICE and
> >> CoRE working groups to ensure that we are fulfilling the needs of
> >> these constituencies.
> >>
> >> NEW:
> >> The Working Group will coordinate its progress with the ACE, DICE,
> >> CoRE
> > and
> >> DIME working groups to ensure that we are fulfilling the needs of
> >> these constituencies.
> >
> > I am not sure that DIME is a reasonable group to be coordinating with
> > since it is not clear that this would be the solution space they are
> > going to operate in.  It is true that this need something along these
> > lines, but what they need first is to get someone who has good
> > knowledge of what can be done in the group first.  Given that this is
> > major (telecom) vendors, using CMS might be a better fit for this
> >
> > The other question if we expand this list here rather than in the wiki
> > is the set of groups that Rene Struik though that might be included
> > here such as "6TiSCH, 6lo, RoLL, etc" which seem to be much closer to
> > the types of groups that might use this specification going forward.
> >
> > At this point, I think I would go with the list we have and start
> > adding more groups to the wiki.
>
> I'm fine with that approach.  My point in bringing up DIME was more that they
> need help and this *could* help them, but work needs to be done to figure
> out what they need at this point.  I brought it up just in case it's relevant to
> COSE.
>
> Thanks,
> Kathleen
> >
> > Jim
> >
> >>
> >>
> >> Thanks,
> >>
> >> Kind Regards
> >> Kepeng
> >>

> >> ? 15/4/15 2:32 am, "Paul Hoffman" <[email-masked]> ??:

> >>
> >>> On Apr 14, 2015, at 11:20 AM, Jim Schaad <[email-masked]>
> wrote:
> >>>>
> >>>> I would like to get Pull Request #2 rolled into the draft charter
> >>>> and then I think we are ready to send it to the ADs and IESG for review.
> >>>>
> >>>> Since it is my pull request I have not done the merge preferring
> >>>> that it be done by one of the others who have permissions.  If I
> >>>> get a message saying do the merge request I would be happy to pull
> >>>> the trigger on it.
> >>>
> >>> There seemed to be general agreement, so I accepted the pull request.
> >>>
> >>> Current version is at:
> >>> https://github.com/cose-spec/wg-charter/blob/master/draft-charter.md
> >>>
> >>> --Paul Hoffman
> >>>
> >>> _______________________________________________
> >>> Cose mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/cose
> >>
> >>
> >> _______________________________________________
> >> Cose mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/cose
> >
> > _______________________________________________
> > Cose mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/cose
>
> _______________________________________________
> Cose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

-- 

Best regards,

Kathleen

-- 

Best regards,

Kathleen

_______________________________________________
Cose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cose

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 24 Apr 2015 14:42:31 +0200

On 04/24/2015 02:22 PM, Jim Schaad wrote:
> Please explain what you mean by point-multipoint settings.  I am not
> familiar with that term .  (I probably know it as something else.)
>

What Göran means are for example publish-subscribe scenarios, where a 
resource representation generated (and encrypted and signed) by one 
publisher is distributed to multiple subscribers.

Another example would be proxy-caches, serving several clients with the 
same cached resource representation from one server (singed and 
encrypted by that server).

>
>     3.What algorithms are we currently using today for those purposes?
>
RFC7252 section 9.1.3.1:

" Implementations in these modes MUST support the mandatory-to-
    implement cipher suite TLS_PSK_WITH_AES_128_CCM_8 as specified in
    [RFC6655]."

and section 9.1.3.2.
"Implementations in RawPublicKey mode MUST support the 
mandatory-to-implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 
as specified in [RFC7251], [RFC5246], and [RFC4492].  The key used MUST 
be ECDSA capable.  The curve secp256r1 MUST be supported [RFC4492]; this 
curve is equivalent to the NIST P-256 curve.  ...."

(and section 9.1.3.3 but that basically repeats the crypto requirements 
from 9.1.3.2)

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: Göran Selander <[email-masked]>
Date: Fri, 24 Apr 2015 14:23:55 +0000

Hi Jim

Thanks for good questions, apologies for not being clear. Ludwig already answered some of the questions, more details inline.

From: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Date: Friday 24 April 2015 14:22
To: Göran Selander <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Cose] Algorithm Questions

From: Göran Selander [mailto:[email-masked]]
Sent: Wednesday, April 22, 2015 11:48 PM
To: Jim Schaad
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Cose] Charter State

No, this is also what I understood. The difference between 40 and 64 bytes overhead may well be that a message supporting the former fits into 802.15.4 without fragmentation whereas the latter doesn’t. (Entire 802.15.4 has a MTU of 127 bytes, but adding various headers (MAC layer, 6LoWPAN, UDP, CoAP, COSE) there has to be something left for payload.)

A short explanation is under “Protection of resource representation” in
https://github.com/cose-spec/use-cases/blob/master/use-cases.md

Two examples are given in section D.2 of
https://tools.ietf.org/html/draft-selander-ace-object-security-01

In the first example (D.2.1) there are two clients accessing the same sensor measurement from a proxy, to avoid loading the server with multiple requests. If the proxy isn’t trusted with the plain text measurement, the message must be encrypted and since there are multiple clients a symmetric encryption algorithm is preferable. If the clients does not trust each other, the message must be signed with the private key of the server.

The second example (D.2.2) is similar, although there is only one subscriber visible in the sequence diagram.

OK, I see what you mean. Much of this depends in general on IoT application and what Class of device is assumed (RFC7228, Table 1). Just to comment on the specific items you raise (others may fill in!):

- A priori, without considering particular cases, I believe we should aim for the same security level as CoAP (RFC7252, section 9), i.e. 128 bits for encryption and signature and 64 bits authentication tag.

For the other items I don’t have as hard facts at hand. My impression is that we shall assume that symmetric primitives are available for all devices of interest, asymmetric not in the most constrained class. When it comes to random numbers, I have heard different views of what could be designed at a low cost, but a conservative assumption is that random number generation is poor.

Thanks
Göran

---

From: Derek Atkins <[email-masked]>
Date: Fri, 24 Apr 2015 12:36:10 -0400

"Jim Schaad" <[email-masked]> writes:

>     In order to get the CFRG pointed in the right direction, it is necessary
>     to give it some input.   To that end I would suggest we start with doing a
>     survey of three questions:
>
>     1.       What type of algorithms are needed?  (key agreement, key
>     transport, signature, hash, MAC, KDF, etc)

For Key Agreement there's the question of data size vs. CPU/Power usage.
For example, Algebraic Eraser can provide a significant CPU/Power
improvement over ECDH (at the cost of addtional bits).

> For the use cases I have in mind: key transport, KDF, encryption/AEAD, hash
> and signature. But the main concern is around signatures.
>
> 1. ECDSA size of signature at 112-128 bits security is of the order of 60
> bytes which is a lot compared to 8 bytes truncated MAC. It would be good to
> have a recommendation of a signature algorithm with message recovery, such as
> ECPVS (which has some IPR, some of which is expiring in a few years) or other.

True, but I've not seen a third-party offline MAC protocol, only 2-party
MACs (or 3-party online systems, like Kerberos).  This is, indeed, why
we want to separate Signatures from MACs -- they have very different use
cases.

> So basically ECDSA, and it’s variants, have a size of 2*|r|, which comes to
> roughly 64 bytes for P-256.  I looked at ECPVS, and for the same level of
> security as the 8 byte truncated MAC I believe you are looking at |r| + 8 or
> 40 bytes for P-256.  It is a message size win, but I am not sure it is as big
> of win as you originally thought it would be. 

I believe that it can be compressed down to |r|+1 bits.

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 24 Apr 2015 12:46:12 -0700

> From: Derek Atkins [mailto:[email-masked]]
> Sent: Friday, April 24, 2015 9:36 AM
> To: Jim Schaad
> Cc: 'Göran Selander'; [email-masked]
> Subject: Re: [Cose] Algorithm Questions
> 
> > For the use cases I have in mind: key transport, KDF, encryption/AEAD,
> > hash and signature. But the main concern is around signatures.
> >
> > 1. ECDSA size of signature at 112-128 bits security is of the order of
> > 60 bytes which is a lot compared to 8 bytes truncated MAC. It would be
> > good to have a recommendation of a signature algorithm with message
> > recovery, such as ECPVS (which has some IPR, some of which is expiring in a
> few years) or other.
> 
> True, but I've not seen a third-party offline MAC protocol, only 2-party MACs
> (or 3-party online systems, like Kerberos).  This is, indeed, why we want to
> separate Signatures from MACs -- they have very different use cases.
> 
> > So basically ECDSA, and it’s variants, have a size of 2*|r|, which
> > comes to roughly 64 bytes for P-256.  I looked at ECPVS, and for the
> > same level of security as the 8 byte truncated MAC I believe you are
> > looking at |r| + 8 or
> > 40 bytes for P-256.  It is a message size win, but I am not sure it is
> > as big of win as you originally thought it would be.
> 

Ah, yes.  I was assuming a particular mode of doing this which would probably not be true. 

I was assuming that you were doing a hash of the message and then doing the recovery on a portion of the hash.  If you do the recovery on the message itself, then the addition of the n bits to the signature (|r| + n) are subtracted from the message thus leading to a signature length of about |r|.  The question that would still need to be addressed is a question of needing to add some additional redundancy bytes to the message.  (And I really don't understand this section of the analysis that I am looking at.)

Jim