Subject: [ietf-types] Request for registration of application/gzip and application/zlib

From: "John R Levine" <[email-masked]>
Date: 21 Feb 2012 10:54:05 -0800

The draft is here:

https://datatracker.ietf.org/doc/draft-levine-application-gzip/

The zlib and gzip formats are defined in RFCs 1950 and 1952. This
defines MIME types for them.

2.  The Application/Zlib Media Type

    Type name: application

    Subtype name: zlib

    Required parameters: none

    Optional parameters: none

    Encoding considerations: needs base64 or other encoding that allows
    arbitrary binary data

    Security considerations: See section [security] below

    Interoperability considerations: none

    Published specification: [RFC1950]

    Applications that use this media type: anywhere data size is an issue

    Additional information:

       Magic number(s): first byte is usually 0x78 but can also be 0x08,
       0x18, 0x28, 0x38, 0x48, 0x58, or 0x68.
       File extension(s): none
       Macintosh file type code(s): none

    Person and email address to contact for further information: see
    http://www.zlib.net/

    Intended usage: COMMON

    Restrictions on usage: none

    Author: John Levine

    Change controller: IETF

3.  The Application/Gzip Media Type

    Type name: application

    Subtype name: gzip

    Required parameters: none

    Optional parameters: none

    Encoding considerations: needs base64 or other encoding that allows
    arbitrary binary data

    Security considerations: See section [security] below

    Interoperability considerations: none

    Published specification: [RFC1952]

    Applications that use this media type: anywhere data size is an issue

    Additional information:

       Magic number(s): first two bytes are 0x1f, 0x8b.
       File extension(s): gz
       Macintosh file type code(s): none

    Person and email address to contact for further information: see
    http://www.gzip.net/

    Intended usage: COMMON

    Restrictions on usage: none

    Author: John Levine

    Change controller: IETF

4.  Security Considerations

    Zlib and gzip compression can be used to compress arbitrary binary
    data such as hostile executable code.  Also, data that purports to be
    in zlib or gzip format may not be, and fields that are supposed to be
    flags, lengths, or pointers, could contain anything.  Applications
    should treat any data with due scepticism.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 21 Feb 2012 21:29:47 +0100

>https://datatracker.ietf.org/doc/draft-levine-application-gzip/

Thank you. The draft should mention that legacy applications have used
application/x-gzip in the past, but that's discouraged, people should
use the types you define instead.

(Most of these comments apply to both types).

>2.  The Application/Zlib Media Type

I would prefer all lower-case for the type name.

>    Encoding considerations: needs base64 or other encoding that allows

The value should be "8bit" (for both types).

>    Interoperability considerations: none

This should probably reference RFC1950.

>    Applications that use this media type: anywhere data size is an issue

Same here.

>       0x18, 0x28, 0x38, 0x48, 0x58, or 0x68.

This is confusing.

>    Person and email address to contact for further information: see

The form in RFC 4288 wants you to use "&" in place of "and".

>    should treat any data with due scepticism.

I would prefer simply referencing the two format RFCs, the types as such
do not introduce additional security considerations.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Ned Freed <[email-masked]>
Date: Tue, 21 Feb 2012 23:23:07 -0800 (PST)

> The value should be "8bit" (for both types).

???? These are binary formats, plain and simple. There's no encoding included
in them that would result in line-oriented output. 

I don't mind changing the wording to simply say "binary" if that is clearer,
but "8bit" is flat-out incorrect.

> This should probably reference RFC1950.

Seems a little redundant, but whatever.

> This is confusing.

Then suggest text. Not sure how else you can say this.

> The form in RFC 4288 wants you to use "&" in place of "and".

No, really, it doesn't. Nothing says the form has to be followed to this
degree.

> do not introduce additional security considerations.

This may need to be reworded to make it clearer, but AFAIK the point that these
formats decode automatically in some contexts and are therefore sometimes used
to get hostile code past overly simplistic scans is not mentioned in those
documents and *is* a known security concern. As such, it needs to be mentioned.

				Ned

---

From: "John R. Levine" <[email-masked]>
Date: 22 Feb 2012 00:15:54 -0800

>>> https://datatracker.ietf.org/doc/draft-levine-application-gzip/

For comments, please see the draft, not just the excepts I posted.  Most 
of Bjoern's comments are already addressed in the current draft.

R's,
John

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 22 Feb 2012 23:55:24 +0100

>but "8bit" is flat-out incorrect.

My apologies, I meant "binary". The nomenclature does confuse me, and I
looked the definitions up again when making the comment, but apparently
it came out wrong. The point is that RFC 4288 says "one of these key-
words", not free-form text.

>Then suggest text. Not sure how else you can say this.

I have not checked whether the above is all that can be said, but if it
is, something like "The first byte is one of ... where 0x78 is the most
common".

>No, really, it doesn't. Nothing says the form has to be followed to this

Well, I look at it from a automated data extraction perspective, and
little details like this make it harder to develop such tools. There
being no good reason to use "&" sometimes and "and" other times, I'd
prefer consistency, but I do agree that this is not a blocker.

>documents and *is* a known security concern. As such, it needs to be mentioned.

That is something the format RFCs should discuss, it's not a media type
issue. With HTTP for instance you do not have automatic decompression
based on the media type, but rather in a separate mechanism.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 23 Feb 2012 00:04:48 +0100

>of Bjoern's comments are already addressed in the current draft.

If you mean draft-levine-application-gzip-00 then the excerpts seem to
be quite equivalent to the draft, and I do not see a more recent draft.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: "John R. Levine" <[email-masked]>
Date: 22 Feb 2012 22:29:10 -0800

>> but "8bit" is flat-out incorrect.

I think I'll leave the current wording.

> I have not checked whether the above is all that can be said, ...

Why not?  It's RFC 1950, section 2.2.

>>> do not introduce additional security considerations.

The draft does reference the two format RFCs.

> based on the media type, but rather in a separate mechanism.

Beyond the fact that the format RFCs were written 15 years ago and aren't 
going to change, the issue here is that MIME parts can be mislabelled. 
Zlib and gzip have an internal structure with pointers and table lookups, 
so data that claims to be zlib but isn't quite could provoke buffer 
overruns and other security holes.

By the way, HTTP has exactly the same vulnerability, since HTTP has gzip 
and deflate content codings.  See RFC 2616, sec 3.5.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Ned Freed <[email-masked]>
Date: Thu, 23 Feb 2012 14:33:12 -0800 (PST)

> words", not free-form text.

The keyword absolutely needs to be included, but free form text is often
helpful in explaining various nuances, and I see nothing in RFC 4288 that
actually prohibits it.

> is, something like "The first byte is one of ... where 0x78 is the most

That also works for me, but frankly I don't think it is any clearer.

> prefer consistency, but I do agree that this is not a blocker.

Um, I doubt very, very much there's any automation involved...

> based on the media type, but rather in a separate mechanism.

As John already pointed out, the RFCs say what they say and that isn't going
to change. Expecting someone to republish an RFC for no other reason than
to change a security considerion of this sort is simply not realistic.

As such, the requirement that security considerations for standards tree
registration trumps any "but there is a better location" argument that can be
made, because said better location doesn't actually exist and isn't going to
exist.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Thu, 23 Feb 2012 14:44:21 -0800 (PST)

> made, because said better location doesn't actually exist and isn't going to

Sorry, this was supposed to read:

  As such, the requirement that security considerations for standards tree
  registrations be as complete as possible trumps any "but there is a better
  location" argument that can be made, because said better location doesn't
  actually exist and isn't going to exist.