W3C home > Mailing lists > Public > www-tag@w3.org > December 2009

Re: Sniffing and HTTP-bis (ACTION-309)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 02 Dec 2009 16:08:26 +0100
Message-ID: <4B1682EA.6010506@gmx.de>
To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
CC: www-tag@w3.org
Henry S. Thompson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> At the TAG f2f in September, we discussed [1] Content-Type sniffing
> and the then-current state of the HTTPbis [2] insofar as it addresses
> this question (see section 3.2.1 *Type*).
> 
> As it stands the draft only indirectly alludes to sniffing, in the
> following paragraph:
> 
>   Content-Type specifies the media type of the underlying data. Any
>   HTTP/1.1 message containing an entity-body SHOULD include a
>   Content-Type header field defining the media type of that body,
>   unless that information is unknown. If the Content-Type header field
>   is not present, it indicates that the sender does not know the media
>   type of the data; recipients MAY either assume that it is
>   "application/octet-stream" ([RFC2046], Section 4.5.1) or examine the
>   content to determine its type.
> 
> Mark Nottingham joined our discussion in September, and said at one
> point:
> 
>   "We were asked to confirm that HTTP bis doesn't conflict with
>    sniffing, and we decided to accept that."
> 
> In later discussion, I said:
> 
>   "I heard TBL say things which suggest we should push back on the
>    current state of the HTTP bis draft. Because it doesn't say 'Don't
>    do that: sniffing breaks things'"
> 
> I took an action [3] to review the situation, and suggest further action
> if necessary.
> 
> I think we should in fact request the HTTPbis editors to reopen their
> Ticket #155 [4] with a suggestion that something along the following
> lines be added after the above-quoted paragraph in section 3.2.1:
> 
>   If the Content-Type header field _is_ present, recipients SHOULD NOT
>   examine the content and override the specified type if the change
>   would significantly alter the security exposure ('privilege
>   escalation').
> 
> This change is compatible with _Content-Type Processing Model_, a
> draft "responsible sniffing" Internet-Draft [5].
> ...

As far as I understand that algorithm, it will sometimes apply sniffing 
to content labeled text/plain, overriding it, for instance, as 
"text/html". Isn't that a significant change of the security exposure???

Best regards, Julian
Received on Wednesday, 2 December 2009 15:09:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:18 GMT