Subject: [lemonade] COMPRESS=mumble

From: Eric Burger <[email-masked]>
Date: Wed, 23 Aug 2006 21:09:02 -0400

In private discussion with some security gurus, they were a bit worried
about the LEMONADE work group defining security-related IANA registries.
Likewise, they are worried that we are going to be mandating requirements on
new TLS parameters to fit our world.

One quick question: Rather than COMPRESS=DEFLATE or COMPRESS=LZS, why not
use COMPRESS=1 and COMPRESS=63?  That is, use the values that already exist
in the already existing registry?

My push back is it is a lot easier to understand "COMPRESS=DEFLATE" than it
is to look up that "1" is DEFLATE.  We also run the risk of people using
0x01.  We could use the DESCRIPTION column from the registry, I suppose.

The alternative is to create a new registry, that looks pretty much
identical to the existing registry. [1]

[1] http://www.iana.org/assignments/comp-meth-ids

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

---

From: Tony Hansen <[email-masked]>
Date: Wed, 23 Aug 2006 23:44:20 -0400

The last time this came up, I hummed to use the description column from
the existing comp-meth-ids registry.

	Tony Hansen
	[email-masked]

---

From: "Ben Last" <[email-masked]>
Date: Thu, 24 Aug 2006 09:04:15 +0100

Eric Burger [mailto:[email-masked]] wrote at 24 August 2006 02:09:
>One quick question: Rather than COMPRESS=DEFLATE or COMPRESS=LZS, why
not use COMPRESS=1 and COMPRESS=63?
>That is, use the values that already exist in the already existing
registry?
I guess one reason is consistency: IMAP is a verbose protocol that tends
to use words rather than numbers, so using the algorithm names follows
that patterns.  Not really a technical rationale, though.

Regards
Ben
EMCC Software Ltd

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 24 Aug 2006 10:42:05 +0100

Eric Burger wrote:

>0x01.
I agree.

>We could use the DESCRIPTION column from the registry, I suppose.
>  
>
Make sense to me.

---

From: Tony Hansen <[email-masked]>
Date: Thu, 24 Aug 2006 08:47:10 -0400

One issue with using the description column found in comp-meth-ids is
that neither RFC 3749 nor RFC 3943 have placed any constraints on the
names to be used in the DESCRIPTION column. While both DEFLATE and LZS
fit our needs perfectly, neither of those RFCs have any verbiage, much
less ABNF, associated with what those names look like.

	Tony Hansen
	[email-masked]

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 24 Aug 2006 14:48:57 +0200

Tony Hansen writes:
> names to be used in the DESCRIPTION column. While both DEFLATE and 
> LZS fit our needs perfectly, neither of those RFCs have any verbiage, 
> much less ABNF, associated with what those names look like.

Easily handled. COMPRESS can say that only if the description column 
meets so-and-so requirements can it be used with IMAP.

Arnt

---

From: Tony Hansen <[email-masked]>
Date: Thu, 24 Aug 2006 08:51:47 -0400

Another possibility is to add additional IANA considerations to the
table, such that there *IS* a description (either verbiage or ABNF)
associated with the DESCRIPTION column.

	Tony Hansen
	[email-masked]

---

From: Tony Hansen <[email-masked]>
Date: Thu, 24 Aug 2006 13:01:44 -0400

So it sounds like Arnt's proposal would be the best compromise:

Names from the DESCRIPTION column can be used for IMAP if and only if
they satisfy these requirements....

	Tony Hansen
	[email-masked]

Eric Rescorla wrote:
> Tony Hansen <[email-masked]> wrote:
> But this has exactly the property that I was concerned about:
> LEMONADE is placing requirements on TLS documents...
> 
> -Ekr

---

From: Lyndon Nerenberg <[email-masked]>
Date: Thu, 24 Aug 2006 12:40:25 -0700 (PDT)

> they satisfy these requirements....

What do we use if the description isn't valid for IMAP?  We would have to 
fall back to the numeric value.  Now what if an update comes along that 
adds a name to an existing entry?  Now you have to support the text 
version as well as the numeric value.  Or not. What a mess.

The protocol is intended to be read by computers, not humans.  While it's 
nice to have readable strings for debugging, it can't be done at the cost 
of adding protocol ambiguity.

I object to the use of text descriptions for this reason; we should 
instead use the numeric value.

--lyndon

---

From: Ken Murchison <[email-masked]>
Date: Thu, 24 Aug 2006 16:11:49 -0400

Lyndon Nerenberg wrote:
> What do we use if the description isn't valid for IMAP?  We would have 
> to fall back to the numeric value.  Now what if an update comes along 
> that adds a name to an existing entry?  Now you have to support the text 
> The protocol is intended to be read by computers, not humans.  While 
> it's nice to have readable strings for debugging, it can't be done at 
> the cost of adding protocol ambiguity.
> 

+1

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

---

From: Curtis King <[email-masked]>
Date: Thu, 24 Aug 2006 14:23:24 -0600

On 24-Aug-06, at 1:40 PM, Lyndon Nerenberg wrote:

> What do we use if the description isn't valid for IMAP?  We would  
> have to fall back to the numeric value.  Now what if an update  
> comes along that adds a name to an existing entry?  Now you have to  
> support the text version as well as the numeric value.  Or not.  
> What a mess.
>
> The protocol is intended to be read by computers, not humans.   
> While it's nice to have readable strings for debugging, it can't be  
> done at the cost of adding protocol ambiguity.
>

+1

ck

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 24 Aug 2006 22:25:43 +0200

Do you guys also think it's unreasonable to add another IANA 
consideration, to force the description column to be suitable?

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 24 Aug 2006 22:39:53 +0200

> consideration, to force the description column to be suitable?

Oh, crap. I deleted too many ccs.

Eric/Glenn: Please permit cc.

Armt

---

From: Randall Gellens <[email-masked]>
Date: Thu, 24 Aug 2006 14:56:04 -0700

>  associated with the DESCRIPTION column.

I'd be happy with this approach, or with not using an IANA registry 
at all.  There was debate over the need for an IANA registry to begin 
with, so now that there are new problems with doing so, let's revisit 
the issue.

Since the intent, as I understand it, is that IMAP (and message 
submission) level compression is to be used as an interim solution 
until TLS compression is widely deployed, and since we don't 
anticipate needing to standardize new compression mechanisms for IMAP 
(or message submission), I suggest we go back to only allowing 
DEFLATE.  We can say that new mechanisms, if needed, can be 
established via standards-track or experimental RFCs that extend the 
COMPRESS command.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Programs that crash have been proven to be less useful than those
that don't.  --Apple Technical Note OV04 (formerly Technote #117)
                developer.apple.com/technotes/ov/ov_04.html

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 24 Aug 2006 09:30:22 -0400

Hi Tony,

> associated with the DESCRIPTION column.

Why not just add a new column to the IANA registry for a new 'ID' attribute 
that follows IMAP Atom syntax requirements.

Another alternative is to use the numeric value followed by some 
descriptive text, e.g.:

COMPRESS=1.DEFLATE
COMPRESS=64.LZS
COMPRESS=227.MYHYPERCOMPRESSOR

The numeric value would be the actual algorithm identifier - the text is 
only their as a 'friendly name' descriptor and MUST NOT be used to identify 
any algorithm.

-- 
Cyrus Daboo

---

From: Ned Freed <[email-masked]>
Date: Thu, 24 Aug 2006 16:21:10 -0700 (PDT)

+1

If my own IANA experiences are any indication, this sort of tweak is not more
difficult than creating a new registry, and may in fact be slightly easier.

> COMPRESS=227.MYHYPERCOMPRESSOR

I'd really rather not do this.

				Ned

---

From: <[email-masked]>
Date: Fri, 25 Aug 2006 06:52:41 +0300

I think that there are two things to this.
One is registration, the other is whether we use the numberic or alpha representation.

My suggestion would be to leave the registry for them (avoid creating yet another registry), and instead of numberic representation use the alpha representation.
Would this work?

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

>-----Original Message-----
>From: ext Eric Burger [mailto:[email-masked]] 
>Sent: 24 August, 2006 04:09
>To: IETF LEMONADE
>Cc: Eric Rescorla
>Subject: [lemonade] COMPRESS=mumble
>
>In private discussion with some security gurus, they were a 
>bit worried about the LEMONADE work group defining 
>security-related IANA registries.
>Likewise, they are worried that we are going to be mandating 
>requirements on new TLS parameters to fit our world.
>
>One quick question: Rather than COMPRESS=DEFLATE or 
>COMPRESS=LZS, why not use COMPRESS=1 and COMPRESS=63?  That 
>is, use the values that already exist in the already existing registry?
>
>My push back is it is a lot easier to understand 
>"COMPRESS=DEFLATE" than it is to look up that "1" is DEFLATE.  
>We also run the risk of people using 0x01.  We could use the 
>DESCRIPTION column from the registry, I suppose.
>
>The alternative is to create a new registry, that looks pretty 
>much identical to the existing registry. [1]
>
>

---

From: <[email-masked]>
Date: Fri, 25 Aug 2006 06:57:17 +0300

I would go for forcing such column. People will refer to each algorithm using their names anyway.
The short name could be the RFC number as well.

>From: ext Arnt Gulbrandsen [mailto:[email-masked]] 
>Sent: 24 August, 2006 23:26
>To: [email-masked]
>Subject: Re: [lemonade] COMPRESS=mumble
>
>Curtis King writes:
>> +1
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 24 Aug 2006 07:27:57 -0700

-Ekr

---

From: Dave Cridland <[email-masked]>
Date: Fri, 25 Aug 2006 09:57:32 +0100

> LEMONADE is placing requirements on TLS documents...

I hear what you're saying, but I seem to be missing why this is a 
problem.

Personally, I agree with the idea that if we were trying to place a 
requirement on a security related registry which affected security, 
that would rightfully raise a few eyebrows.

But we're not talking about a security related registry. We're 
talking about a compression related registry, which is almost a good 
fit for what we're after - indeed, all the current registrations are 
perfectly formed for us. It happens to be defined relating to TLS, 
but that's really the only "security" issue. We're just after either 
another column, or a retrofitted syntactic requirement on the 
"DESCRIPTION" column which maintains the status quo. This was 
certainly the consensus of the group as I understood it.

And we're absolutely not talking about anything which affects 
security - you say "requirements on TLS documents", but really, this 
would only place requirements on TLS *COMPRESSION* documents. That's 
a requirement on *TWO* documents in the history of TLS, so far. Of 
course, I'm possibly unaware of some enormous activity within the 
security area on compression which'll be defining new compression 
methods for TLS by the dozen, but I don't understand why mandating 
that such documents include a short alphanumeric string uniquely 
identifying the algorithm is such a problem.

It's not as if compression algorithms don't have names, and even if 
they didn't, this is not a security-related requirement. The only 
relation compression has to TLS is that TLS happens to provide the 
facility - it's really nothing to do with security at all. Arguably, 
TLS compression documents shouldn't come from the Security Area at 
all.

Personally, I feel that a single registry covering all compression 
algorithms would benefit the general architecture of the IETF 
enormously over a series of disconnected registries.

If you can come up with a technical reason why we can't make a minor 
adjustment to the registry, or if the IAB makes a formal statement on 
the issue, then for the record, I'll have to say we ditch the 
registry entirely (ie, follow Randy's suggestion). But my strong 
preference is to leverage the existing registry (ie, follow Ned 
Freed's suggestion).

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 25 Aug 2006 13:57:04 +0100

I've replied directly to Dave and Eric. Dave asked me to reply to the 
mailing list.

Dave Cridland wrote:

> But we're not talking about a security related registry. We're talking 
> about a compression related registry, which is almost a good fit for 
> what we're after - indeed, all the current registrations are perfectly 
> formed for us. It happens to be defined relating to TLS, but that's 
> really the only "security" issue. We're just after either another 
> column, or a retrofitted syntactic requirement on the "DESCRIPTION" 
> column which maintains the status quo. This was certainly the 
> consensus of the group as I understood it.
>
> And we're absolutely not talking about anything which affects security 
> - you say "requirements on TLS documents", but really, this would only 
> place requirements on TLS *COMPRESSION* documents. That's a 
> requirement on *TWO* documents in the history of TLS, so far. Of 

+1

> TLS compression documents shouldn't come from the Security Area at all.
>

+1

> the issue, then for the record, I'll have to say we ditch the registry 
> entirely (ie, follow Randy's suggestion). But my strong preference is 
> to leverage the existing registry (ie, follow Ned Freed's suggestion).

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Aug 2006 06:52:51 -0700

> I hear what you're saying, but I seem to be missing why this is a

Obviously.

> identifying the algorithm is such a problem.

You're assuming that's the only set of requirements, but that's not
clear. I haven't studied the problem extensively, but it may or may not
be the case that the technical requirements for TLS compression
algorithms match the ones for LEMONADE compression algorithms. I know,
for instance, that TLS compression algorithms have different
requirements than DTLS compression algorithms, despite the fact that
those two protocols are very closely related.

So, the situation I'm trying to avoid is one in which someone
wants to define a new compression algorithm for TLS and people
find it's inappropriate for LEMONADE or vice versa. 

> TLS compression documents shouldn't come from the Security Area at all.

Arguably so, but this doesn't amount to an argument that they
should be defined in LEMONADE.

> enormously over a series of disconnected registries.

Sure, but the first thing that would require would be an explicit
statement of the protocol architectural interface that those
algorithms were expected to provide, rather than the implicit
one that happens to derive from TLS's characteristics.	

I fail to see what the "enormous" benefit of having one registry
with three columns in it is over having two registries with
two columns each.

-Ekr

---

From: Ted Hardie <[email-masked]>
Date: Fri, 25 Aug 2006 11:39:12 -0700

At 6:52 AM -0700 8/25/06, Eric Rescorla wrote:
>algorithms match the ones for LEMONADE compression algorithms.

Perhaps I misunderstood this, but I believe the working group previously
discussed using these explicit compression algorithms until TLS
compression is more widely deployed.  So there are two points of
connection here--these existing compression algorithms do match
and there is an intent to transition toward using TLS compression
more generally.

(If I misunderstood the state of play here, sorry; please let me know).

There might be, of course, conditions later where no TLS is present and
compression is desired using some later non-TLS-friendly compression
algorithm.  But if I understand things correctly, that would be a change
in design goals, which seem to be at the moment "compression should
be tls-friendly" trending into "should be done in TLS" in the future.
Revisiting the registry question at that point would make sense.

In the short term, though, I suspect that skipping the registry is reasonable.
The document will provide the names, and if there is a later need to
expand them to include more algorithms, we'll have more data points
to use in deciding whether the TLS-friendly aspect is a design constraint
or not.
			regards,
				Ted

---

From: Dave Cridland <[email-masked]>
Date: Fri, 25 Aug 2006 23:09:00 +0100

> > > I hear what you're saying, but I seem to be missing why this is 
I should hope it was obvious, given that I said so.

> those two protocols are very closely related.
Well, DTLS being datagram based, this would make sense. But both TLS 
and TCP provide an essentially streamed interface, albeit TLS has the 
framing information provided by an octet count.

> find it's inappropriate for LEMONADE or vice versa. 
I'm not convinced that's at all likely. You're basically saying that 
someone would need to find a compression algorithm such that it would 
need octet counting in its encoded state. That is to say, that the 
algorithm would fail if there were more compressed data after the 
compressed data it was operating on.

I cannot conceive of such an algorithm, nor can I find any criteria 
at all which would prevent a COMPRESS=x algorithm from working as a 
TLS compression method.

So I'll go for impossible in one direction, and highly improbable in 
the other.

> one that happens to derive from TLS's characteristics.	
Yes, absolutely. I'd consider that valuable work. Then a compression 
algorithm document could simply tick a handful of boxes and be 
available to a much wider range of protocols.

> with three columns in it is over having two registries with

Obviously. :-)

I used the word enormous concerning a single registry for compression 
algorithms, rather than the merely avoiding a single additional one.

I still don't think that there's any real technical issue here at 
all, but this is going nowhere, so I'll assume we'll simply ditch the 
registry concept entirely for the sake of a quiet life.

Dave.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Aug 2006 16:49:40 -0700

Dave Cridland <[email-masked]> wrote:
> I cannot conceive of such an algorithm, nor can I find any criteria at
> all which would prevent a COMPRESS=x algorithm from working as a TLS
> compression method.

Well, it's not particularly difficult: one that potentially expands
the data more than 1024-bytes, which is forbidden by RFC 3749.

> I still don't think that there's any real technical issue here at all,
> but this is going nowhere, so I'll assume we'll simply ditch the

Fine by me.

-Ekr

---

From: Tony Finch <[email-masked]>
Date: Tue, 29 Aug 2006 19:51:34 +0100

> be tls-friendly" trending into "should be done in TLS" in the future.

"Later"? What about security layers negotiated with SASL? Are we expecting
them to provide their own compression, or should they leave it to
application level compression?

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.