search

cose-wg / cose-issues

COSE Working Group Issues
0 stars 1 forks source link

Restore compression header parameter #22

Closed selfissued closed 8 years ago

selfissued commented 8 years ago

Please restore the “zip” header parameter definition. Having a standard way to compress the plaintext before encryption is an important capability. I didn’t see a compelling motivation for its removal when it was briefly discussed on the mailing list.

LudwigSeitz commented 8 years ago

I am not in favour of having this parameter in the COSE spec. The reason is that I suspect it will not be used very much in the constrained space, and if this parameter can be part of a message, I have to implement code on my constrained device to handle it. Keep in mind that we are dealing with devices that can have as little as 100 KB of flash memory for code libraries and other persistent data (See Class 1, Section 3 RFC 7228).

jimsch commented 8 years ago

CRIME has demonstrated that we do not understand how to do generic compression. This means that compression needs to be an application specified feature and not a security feature. This is a strong justification for removal of compression from COSE.

cose-ietf commented 8 years ago

Hi Ludwig

Is this also true based on yesterday's presentation where it was mentioned that communication is orders of magnitude more energy than computation. I doubt there is anything to compress o on an already efficient encoding but will not completely dismiss its need in the constrained space.

Sandeep

From: COSE [cose-bounces@ietf.org] on behalf of LudwigSeitz [notifications@github.com] Sent: Wednesday, November 4, 2015 1:44 AM To: cose-wg/cose-issues Subject: Re: [COSE] [cose-issues] Restore compression header parameter (#22)

I am not in favour of having this parameter in the COSE spec. The reason is that I suspect it will not be used very much in the constrained space, and if this parameter can be part of a message, I have to implement code on my constrained device to handle it. Keep in mind that we are dealing with devices that can have as little as 100 KB of flash memory for code libraries and other persistent data (See Class 1, Section 3 RFC 7228).

� Reply to this email directly or view it on GitHubhttps://github.com/cose-wg/cose-issues/issues/22#issuecomment-153535305.

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

cabo commented 8 years ago

I'm sympathetic with Ludwig's point, however, it should be the prerogative of the enclosing media type to define whether decompression capability is expected or not. (Also, we have to be careful about equating compression with deflate. There are other schemes that are more appropriate for decompression on constrained devices.)

selfissued commented 8 years ago

The CRIME argument is persuasive. I'm willing to drop this request on that basis. Thanks to all who discussed the possibility.