Subject: [COSE] Compression of content

From: "Jim Schaad" <[email-masked]>
Date: Sat, 3 Oct 2015 17:29:43 -0700

I intend to remove the parameter which tags the ability to do compression of
content.

I do not believe that this is of interest in the IoT world.  If it becomes
necessary later for other systems it can be defined then.

Jim

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 04 Oct 2015 04:22:30 +0200

Interesting.

-- With the JOSE versions of these parameters already defined, what is
the practical effect of not having that parameter here?  Implementations
that want it are likely to simply use it anwyay.
(However, in JOSE this is a "MUST understand" parameter -- if we don't
have it initially, it can't be that, and the usage it is going to get
anyway is maybe perilous.)

-- More meta: Are we really in the business of guessing what is of
interest in the IoT world?  Where we optimize specifically for the IoT
world, we of course have to.  But do we have to make a consensus
decision about that for every single parameter of JOSE?

Grüße, Carsten

Jim Schaad wrote:
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose
>

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 3 Oct 2015 19:33:55 -0700

> -----Original Message-----
> From: Carsten Bormann [mailto:[email-masked]]
> Sent: Saturday, October 03, 2015 7:23 PM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [COSE] Compression of content
> 
> Interesting.
> 
> -- With the JOSE versions of these parameters already defined, what is the
> practical effect of not having that parameter here?  Implementations that want
> it are likely to simply use it anwyay.
> (However, in JOSE this is a "MUST understand" parameter -- if we don't have it
> initially, it can't be that, and the usage it is going to get anyway is maybe
> perilous.)

Are you arguing that we should keep it?  Going either way is easy, but pulling it is a quicker finish.

> 
> -- More meta: Are we really in the business of guessing what is of interest in the
> IoT world?  Where we optimize specifically for the IoT world, we of course have
> to.  But do we have to make a consensus decision about that for every single
> parameter of JOSE?

This is why I am advertising what I plan to do.  So that people have a chance to give a solid argument to keep it if they think it should be kept.   There do seem to be some that think that the IoT world is really all that we should care about. 

Jim

> 
> Grüße, Carsten
> 
> 
> Jim Schaad wrote:
> > I intend to remove the parameter which tags the ability to do
> > compression of content.
> >
> > I do not believe that this is of interest in the IoT world.  If it
> > becomes necessary later for other systems it can be defined then.
> >
> > Jim
> >
> >

---

From: Mike Jones <[email-masked]>
Date: Sun, 4 Oct 2015 05:34:16 +0000

I believe that removing the compression capability doesn't pass the chairs' test "What Would JOSE Do?".  (See slide 14 in the chairs' presentation https://www.ietf.org/proceedings/93/slides/slides-93-cose-2.pdf and the following slides.)

Carsten's point that compression is a "must understand" feature is also important.  If we don't keep it now, we'll never be able to obtain the important "must understand" property after the fact.

I have heard no compelling reason to remove compression.  Therefore, we should keep it.

				-- Mike

-----Original Message-----
From: COSE [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Saturday, October 03, 2015 7:34 PM
To: 'Carsten Bormann'
Cc: [email-masked]
Subject: Re: [COSE] Compression of content

> the practical effect of not having that parameter here?  
> Implementations that want it are likely to simply use it anwyay.

Jim

> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww
> > .ietf.org%2fmailman%2flistinfo%2fcose&data=01%7c01%7cMichael.Jones%4
> > 0microsoft.com%7c6c9c6326813542907faf08d2cc649e62%7c72f988bf86f141af
> > 91ab2d7cd011db47%7c1&sdata=pdSJYs5BMeV6YeZR%2fc4gAkF0yy4SIjh494q%2fy
> > NKysUY%3d
> >

_______________________________________________
COSE mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fcose%0a&data=01%7c01%7cMichael.Jones%40microsoft.com%7c6c9c6326813542907faf08d2cc649e62%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ZVRSqXYMRyXrSTLsVtjYSjRFtrOGZU4Vn%2fQBzyUckoE%3d

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 04 Oct 2015 11:45:56 +0200

> Are you arguing that we should keep it?  Going either way is easy, but pulling it is a quicker finish.

Not really *arguing* for keeping it right now.  I'm focusing on
understanding how we can keep COSE modular.  So if this is something
that could be put into a "module" that specific COSE applications don't
have to require, I'd be happy.  I'd like to understand the "MUST
understand" requirement from JOSE a bit better.

> This is why I am advertising what I plan to do.  So that people have a chance to give a solid argument to keep it if they think it should be kept.   There do seem to be some that think that the IoT…

The IoT world is big, and, as Hannes keeps reminding us, also includes
quite capable devices alongside the basic microcontrollers RFC 7228 is
addressing.  Also, from the other end, compression techniques are
getting better -- most people probably think about the overhead of
DEFLATE, while there are now much more frugal schemes such as LZ4 in
wide deployment.  So while compression is still nothing that would help
much for class 1 devices, there is a continuum upwards where compression
may enter the IoT picture at some point for some applications.

Grüße, Carsten

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 4 Oct 2015 13:40:15 +0300

> understand" requirement from JOSE a bit better.

Maybe dumb question, but: Have compressed messages contain "crit" header
(0x02 in the current spec) refencing "zip" header (with numeric value
assigned if needed). Why won't that work?

Crit header apparently has intended purpose of designating various
nonstandard header fields to be important for interpretting the
message.

-Ilari

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 4 Oct 2015 10:25:27 -0700

We are not making any statements about must understand in the COSE documents.  We are providing features that application profiles are going to be able to say it must be understood, or it must be ignored.  I don't buy that as an argument about saying that it needs to be included now.

Jim

> From: Mike Jones [mailto:[email-masked]]
> Sent: Saturday, October 03, 2015 10:34 PM
> To: Jim Schaad <[email-masked]>; 'Carsten Bormann' <[email-masked]>
> Cc: [email-masked]
> Subject: RE: [COSE] Compression of content
> 
> I believe that removing the compression capability doesn't pass the chairs' test
> "What Would JOSE Do?".  (See slide 14 in the chairs' presentation
> https://www.ietf.org/proceedings/93/slides/slides-93-cose-2.pdf and the
> following slides.)
> 
> Carsten's point that compression is a "must understand" feature is also
> important.  If we don't keep it now, we'll never be able to obtain the important
> "must understand" property after the fact.
> 
> This is why I am advertising what I plan to do.  So that people have a chance to
> give a solid argument to keep it if they think it should be kept.   There do seem to
> be some that think that the IoT world is really all that we should care about.
> 
> Jim
> 
> >
> > Grüße, Carsten
> >
> >
> > Jim Schaad wrote:
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.
> org%2fmailman%2flistinfo%2fcose%0a&data=01%7c01%7cMichael.Jones%40m
> icrosoft.com%7c6c9c6326813542907faf08d2cc649e62%7c72f988bf86f141af91
> ab2d7cd011db47%7c1&sdata=ZVRSqXYMRyXrSTLsVtjYSjRFtrOGZU4Vn%2fQBzyU
> ckoE%3d

---

From: Mike Jones <[email-masked]>
Date: Sun, 4 Oct 2015 17:57:57 +0000

That's certainly not true.  For instance, I'm sure we're making a statement that the algorithm header parameter must be understood (whether it's worded that way or not).

You didn't answer my main point, which is that there needs to be a compelling case stated to remove it if we're going to do so and the working group needs to agree with that case - something that hasn't happened.  Otherwise, given it's important functionality, our default decision should be to retain it.

				-- Mike

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Sunday, October 04, 2015 10:25 AM
To: Mike Jones; 'Carsten Bormann'
Cc: [email-masked]
Subject: RE: [COSE] Compression of content

Jim

> I believe that removing the compression capability doesn't pass the 
> chairs' test "What Would JOSE Do?".  (See slide 14 in the chairs' 
> presentation 
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i
> etf.org%2fproceedings%2f93%2fslides%2fslides-93-cose-2.pdf&data=01%7c0
> 1%7cMichael.Jones%40microsoft.com%7ccae98a10553448c7a4f208d2cce1272a%7
> c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=a1X91Q2GkbhB23vhriXIs2JY2V
> iSzvYuP49At9EYcTk%3d and the following slides.)
> 
> Carsten's point that compression is a "must understand" feature is 
> also important.  If we don't keep it now, we'll never be able to 
> obtain the important "must understand" property after the fact.
> 
> > -- With the JOSE versions of these parameters already defined, what 
> > is the practical effect of not having that parameter here?
> > (However, in JOSE this is a "MUST understand" parameter -- if we 
> > don't have it initially, it can't be that, and the usage it is going 
> > to get anyway is maybe
> > perilous.)
> 
> > interest in the IoT world?  Where we optimize specifically for the 
> > IoT world, we of course have to.  But do we have to make a consensus

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 4 Oct 2015 21:54:46 -0700

In a word CRIME.

There have been some significant attacks against compression in TLS and other places where the amount of compression is leaking information about the content.  For this reason compression is being removed from TLS entirely.  The statement being made is that for protocols that need compression, it is significantly better for the protocols to provide the compression inside of the protocol where they can do the appropriate security analysis.

jim

> Sent: Sunday, October 04, 2015 10:58 AM
> That's certainly not true.  For instance, I'm sure we're making a statement that
> the algorithm header parameter must be understood (whether it's worded that
> way or not).
> 
> You didn't answer my main point, which is that there needs to be a compelling
> case stated to remove it if we're going to do so and the working group needs to
> agree with that case - something that hasn't happened.  Otherwise, given it's
> important functionality, our default decision should be to retain it.
> 
> 				-- Mike
> 
> We are not making any statements about must understand in the COSE
> documents.  We are providing features that application profiles are going to be
> able to say it must be understood, or it must be ignored.  I don't buy that as an
> argument about saying that it needs to be included now.
> 
> Jim
>

---

From: Samuel Erdtman <[email-masked]>
Date: Mon, 5 Oct 2015 07:08:07 +0200

I cannot se the big benefit of removing it and I like the idea of COSE
going as much as possible in line with JOSE so that if I´m familiar with
one of the protocols I would quickly understand the other one.

Best Regards
Samuel Erdtman

On Sun, Oct 4, 2015 at 4:22 AM, Carsten Bormann <[email-masked]> wrote:

> compression of
> becomes