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 protected]<mailto:[email protected]>> wrote:
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
_______________________________________________
jose mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
