[media-types] Request for review of Media Type application/lzip

[Antonio Diaz Diaz <[e-mail]>]

Dear media types experts,

I'm about to submit an Internet Draft of an informational RFC with the 
specification of the lzip format and an IANA Considerations section 
requesting the registrations of the Media Type 'application/lzip' and the 
Content Type 'lzip'. I'm posting the IANA part of the draft here for review. 
Thanks.

The type is "widely" deployed. Most archivers support the lzip format. Many 
browsers and package managers support the media type as application/x-lzip. 
The IANA Time Zone Database[1] is distributed in lzip format (and the IANA 
server identifies the tar.lz files as application/x-lzip).
[1] http://www.iana.org/time-zones

At least one application (GNU Wget2) is implementing 'lzip' as a content 
coding for http. In fact the maintainers of Wget2 suggested me to register 
the type, which would perhaps minimize the work required in the future to 
deprecate the unregistered type application/x-lzip. I learned about the 
problems caused by the "x-" prefix at
http://tools.ietf.org/html/rfc6648#appendix-B

Thank you very much,
Antonio.


Your Full Name:                 Antonio Diaz Diaz
Your E-mail:                    [e-mail]

4.1.  The 'application/lzip' Media Type

    The 'application/lzip' media type identifies a block of data that is
    compressed using lzip compression.  The data is a stream of bytes as
    described in this document.  IANA has added the following to the
    "Media Types" registry:

    Type name:  application

    Subtype name:  lzip

    Required parameters:  N/A

    Optional parameters:  N/A

    Encoding considerations:  binary

    Security considerations:  See Section 5 of RFC XXXX (copied below)

    Interoperability considerations:  N/A

    Published specification:  RFC XXXX

    Applications that use this media type:
       Any application where data size is an issue

    Fragment Identifier Considerations:  N/A

    Restrictions on Usage:  N/A

    Provisional Registrations:  N/A

    Additional information:

       Deprecated alias names for this type:  application/x-lzip

       Magic number(s):  First 4 bytes (0x4C, 0x5A, 0x49, 0x50)

       File extension(s):  .lz .tlz

       Macintosh File Type Code(s):  N/A

       Object Identifier(s) or OID(s):  N/A

    Intended Usage:  COMMON

    Other Information & Comments:  See [LZIP] (copied below)

    Author:  Antonio Diaz Diaz

    Change Controller:  IETF

4.2.  Content Encoding

    IANA has added the following entry to the "HTTP Content Coding
    Registry" within the "Hypertext Transfer Protocol (HTTP) Parameters"
    registry:

    Name:  lzip

    Description:  A stream of bytes compressed using lzip compression

    Pointer to specification text:  RFC XXXX

5.  Security Considerations

    Lzip is a compressed format.  Decompression of the data may expand it
    to a size more than 7000 times larger, risking an out-of-memory or
    out-of-disc-space condition.  Since both the gzip and lzip formats
    contain a single data stream, any steps already taken to avoid such
    attacks on application/gzip should also work on application/lzip.
    One possible measure, already implemented in some applications, is to
    set a limit to the decompressed size and stop the decompression or
    warn the user if the limit is surpassed.

    This media type does not employ any kind of "active content", but it
    can be used to compress any other media type (for example
    application/postscript) which could then be interpreted by the
    application.

    A lzip stream does not store any metadata.  Any data appended to the
    end of the stream is easily detected, and an error can be signaled.
    It is not apparent how this media type could be used to help violate
    a recipient's privacy.

    The lzip media type does not need itself any external security
    mechanisms.  But again, it can be used to compress other media types
    requiring them (for example a media type defined for storage of
    sensitive medical information).

    Because of the nature of the decoding algorithm used by lzip, it is
    easy to protect the decoder from invalid memory accesses caused by
    corruption in the input data (intentional or not).  Size limits need
    to be checked at just one place in the decompressor (the decoding of
    rep0) to prevent buffer overflows.  This has been extensively tested
    with a specialized tool (unzcrash) distributed with the lziprecover
    tool.

    The lzip data stream does not contain any size fields that can be
    faked to be smaller than the actual decompressed data in an attempt
    to trigger a buffer overflow.  (The 'Data size' field in the lzip
    trailer is only used to verify the size of the data produced as an
    error detection measure).

6.1.  Normative References

    [LZIP]     "Lzip", <http://www.nongnu.org/lzip/lzip.html>.