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

Henry S. Thompson wrote:
> 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 UTC