Subject: [jose] COSE: what would change?

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Fri, 6 Mar 2015 19:19:25 +0000

In talking with several folks about COSE, it appears that there are differing views on how much to change in the JOSE/COSE translation.  I would like to explore the points of agreement and disagreement a little.

It seems like most people agree that maintaining signature compatibility is a non-goal; I agree that is the only way for us to have a chance at success.

I think we're also likely to get agreement that we should do our best to use CBOR idioms in COSE (such as mixed-type keys for maps) once they are explained to the group in enough detail for everyone to understand the proposals.

Finally, I think one of the reasons people are interested in COSE is a chance to optimize for a different set of use cases than we had for JOSE.

The main source of disagreement seems to be what we would change in COSE of the things some might have wanted to done differently in JOSE.  I'm sympathetic to both the group that wants to crank something out quickly without re-litigating the past, as well as to the group that wants to re-optimize as many things as possible given the removal of the pressure of existing codebases that we had with JOSE.

An approach that might work for this would be to set a bar for changes along the lines of "significant improvement in security, performance (wire size, code size, CPU, power, etc.), or deployability" would be required to justify a change.  To see if that approach would work, it would be nice to see a list of things that folks would want to change, and to get early agreement on a couple of those changes as being above the bar that we set, so that we have some precedent to reason from. 

To that end, I propose that those that want changes produce a list, perhaps annotated with whether the change is seen as imperative or merely nice-to-have.  The folks that want a quick outcome would then select several changes they see as being definitely above the line.  My hope is that this exercise would build trust that we all want something similar: a high quality protocol standardized in as short a time as possible.

-- 
Joe Hildebrand

---

From: Mike Jones <[email-masked]>
Date: Fri, 6 Mar 2015 19:43:29 +0000

Thanks for writing this, Joe.  I know that people from the IoT and other communities are already itching for a CBOR JOSE encoding and we'll do everyone a service by providing one in a timely fashion.

I think your proposal to set a high, well-understood and agreed upon bar for any changes to the decisions made in JOSE is the key to having this complete in a reasonable period of time.  In my view, if we open most decisions to be re-debated, our timeline is far more likely to look like the JOSE timeline (in which we had the WOES BoF in July 2011 and are only nearing having RFCs now over 3.5 years later) than the quick turnaround achievable by building on past work that I think we would all like.

Getting down to specifics, looking at the two COSE submissions to date, https://tools.ietf.org/html/draft-bormann-jose-cose-00 and http://tools.ietf.org/html/draft-schaad-cose-00, I think Carsten's submission is more effective at leveraging our existing decisions than Jim's does so I'd personally want to use that as a starting point, but there are some things I find valuable in Jim's draft as well.  For instance, I think that we should consider using arrays rather than maps at the top level, as Jim suggests, as it may keep the code simpler and the representations more compact.  I'll note that this is actually parallel to the JOSE Compact Serializations, which used data structures with fixed numbers of elements in fixed positions at the top level, rather than JSON objects, as was done in the JSON Serializations.

I'll also add that I personally think we should only define one serialization for the CBOR encoding.  I would justify this departure from JOSE as being in the name of "keeping simple things simple" - something I think should also be part of our criteria when making our decisions.  (If people do need a URL-safe representation of a COSE object, it would be fine for them to base64url encode the whole thing, for transmission purposes - a suggestion that Joe made to me in person in Honolulu.)

Anyway, I'm glad to see this discussion and look forward to us hopefully completing a COSE standard within a year from now!

				-- Mike

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Joe Hildebrand (jhildebr)
Sent: Friday, March 06, 2015 11:19 AM
To: [email-masked]
Subject: [jose] COSE: what would change?

-- 
Joe Hildebrand

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

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 10 Mar 2015 11:14:58 +0200

Arrays would be good. Perhaps even bit fields?

We recently had a use case where we had to constrain the size of JWTs
and we successfully compressed an array of various constant claims into
a base64 encoded bit field, giving us  significant space saving.

Vladimir

-- 
Vladimir Dzhuvinov :: [email-masked]

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 11 Mar 2015 22:49:06 +0900

We have something similar as well...

2015-03-10 18:14 GMT+09:00 Vladimir Dzhuvinov <[email-masked]>:

> > Thanks for writing this, Joe.  I know that people from the IoT and other
> communities are already itching for a CBOR JOSE encoding and we'll do
> everyone a service by providing one in a timely fashion.
> >
> > I think your proposal to set a high, well-understood and agreed upon bar
> for any changes to the decisions made in JOSE is the key to having this
> complete in a reasonable period of time.  In my view, if we open most
> decisions to be re-debated, our timeline is far more likely to look like
> the JOSE timeline (in which we had the WOES BoF in July 2011 and are only
> nearing having RFCs now over 3.5 years later) than the quick turnaround
> achievable by building on past work that I think we would all like.
> >
> > Getting down to specifics, looking at the two COSE submissions to date,
> https://tools.ietf.org/html/draft-bormann-jose-cose-00 and
> http://tools.ietf.org/html/draft-schaad-cose-00, I think Carsten's
> submission is more effective at leveraging our existing decisions than
> Jim's does so I'd personally want to use that as a starting point, but
> there are some things I find valuable in Jim's draft as well.  For
> instance, I think that we should consider using arrays rather than maps at
> the top level, as Jim suggests, as it may keep the code simpler and the
> representations more compact.  I'll note that this is actually parallel to
> the JOSE Compact Serializations, which used data structures with fixed
> numbers of elements in fixed positions at the top level, rather than JSON
> objects, as was done in the JSON Serializations.
> >
> > I'll also add that I personally think we should only define one
> serialization for the CBOR encoding.  I would justify this departure from
> JOSE as being in the name of "keeping simple things simple" - something I
> think should also be part of our criteria when making our decisions.  (If
> people do need a URL-safe representation of a COSE object, it would be fine
> for them to base64url encode the whole thing, for transmission purposes - a
> suggestion that Joe made to me in person in Honolulu.)
> >
> > Anyway, I'm glad to see this discussion and look forward to us hopefully
> completing a COSE standard within a year from now!
> >
> >                               -- Mike
> >
> > In talking with several folks about COSE, it appears that there are
> differing views on how much to change in the JOSE/COSE translation.  I
> would like to explore the points of agreement and disagreement a little.
> >
> >
> > It seems like most people agree that maintaining signature compatibility
> is a non-goal; I agree that is the only way for us to have a chance at
> success.
> >
> >
> > I think we're also likely to get agreement that we should do our best to
> use CBOR idioms in COSE (such as mixed-type keys for maps) once they are
> explained to the group in enough detail for everyone to understand the
> proposals.
> >
> > Finally, I think one of the reasons people are interested in COSE is a
> chance to optimize for a different set of use cases than we had for JOSE.
> >
> >
> > The main source of disagreement seems to be what we would change in COSE
> of the things some might have wanted to done differently in JOSE.  I'm
> sympathetic to both the group that wants to crank something out quickly
> without re-litigating the past, as well as to the group that wants to
> re-optimize as many things as possible given the removal of the pressure of
> existing codebases that we had with JOSE.
> >
> >
> > An approach that might work for this would be to set a bar for changes
> along the lines of "significant improvement in security, performance (wire
> size, code size, CPU, power, etc.), or deployability" would be required to
> justify a change.  To see if that approach would work, it would be nice to
> see a list of things that folks would want to change, and to get early
> agreement on a couple of those changes as being above the bar that we set,
> so that we have some precedent to reason from.
> >
> >
> > To that end, I propose that those that want changes produce a list,
> perhaps annotated with whether the change is seen as imperative or merely
> nice-to-have.  The folks that want a quick outcome would then select
> several changes they see as being definitely above the line.  My hope is
> that this exercise would build trust that we all want something similar: a
> high quality protocol standardized in as short a time as possible.
> >
> >
>
> --

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Mar 2015 15:12:59 +0100

Nat Sakimura wrote:
> 2015-03-10 18:14 GMT+09:00 Vladimir Dzhuvinov <[email-masked]
> <mailto:[email-masked]>>:
> 

Do you guys have some examples that we could look at?

(CDDL just got support for bit fields, by the way; the current draft
only has it for byte strings, the tool already also supports specifying
them for uints.)

Grüße, Carsten

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Wed, 11 Mar 2015 18:23:30 +0200

This is the class that we use to compress JSON string arrays:

https://gist.github.com/anonymous/ee61ff43d3fe76d8d7e0

For example the array

["apple","pear","orange","mango","fig"]

to

["!Jg"]

For that you would need a compression table like this:

0 : apple
1 : pear
2 : orange
3 : mango
4 : fig
5 : ...

where the most frequent words should be at the top, and rarely used
words at the bottom.

Cheers,

Vladimir

---

From: John Mattsson <[email-masked]>
Date: Fri, 20 Mar 2015 08:23:13 +0000

Thanks for starting the discussion Joe,

I strongly support the work on COSE. My view is that to be relevant for the IoT use cases, and in particular devices using IEEE 802.15.4, COSE must be highly optimized compared to JOSE:

In our draft on end-to-end security for IoT (draft-selander-ace-object-security-01) were we plan to use COSE, our measurements show that usage of JWS can easily add 135 bytes, filling up more than an entire IEEE 802.15.4 frame.  COSE (according to draft-bormann-jose-cose-00) would be far better but still use 70 bytes. My view is that this is still to large for IEEE 802.15.4 and that the following three optimizations are needed (imperative):

- Carsten has already suggested replacing certain member names ("alg"...) with predefined numbers. I strongly support this.

- Even without base64 encoding, the JWS MACs takes 32 bytes. IoT devices using DTLS use 8 byte MACs. I strongly think IoT specific algorithms with truncated MACs (maybe 16 and 8 bytes) are necessary.

- The JWE Initialization Vector takes up 12 bytes, IoT devices would likely want to save a nonce together with the key to save bandwidth (and therefore battery).

With these changes, the overhead of COSE (both CWS and CWE) could be below 30 bytes. I think this not only desirable, but also necessary. The algorithm and IV optimizations could be done in parallel to the COSE encoding work.

Cheers,
John

———————————————————————
John Mattsson
Ericsson IETF Security Coordinator
Senior Researcher, Security

On 06 Mar 2015, at 20:19, Joe Hildebrand (jhildebr) <[email-masked]<mailto:[email-masked]>> wrote:

--
Joe Hildebrand

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