Re: TAG requests addition to section 3.2.1 of Part 3 [#155]

On 19.05.2010 14:05, Mark Nottingham wrote:
> ...
> My reaction to reading that is that these requirements are so watered down as to be meaningless; they require implementers to make very subjective judgement calls based on evidence of errors and security exposure, with almost no guidelines.
>
> Would the TAG be satisfied if this were rewritten in advisory language (i.e., without RFC2119 keywords)?
>
> E.g., keep the first two paragraphs, but change the third to
>
> """
> There are two risks of such 'sniffing.' First, the sniffed type may not be
> that of the actual document, preventing the server from having their
> intent honoured. For example, a simplistic HTML sniffing algorithm might
> be fooled by a text/plain document containing the word 'HTML' near its top.
>
> Secondly, sniffing exposes implementations to security escalations. For
> example, if a server sets a content-type of an uploaded file to text/plain,
> but a client sniffs it as text/html, an attacker might take advantage of
> this to mount a cross-site scripting attack.
> """

+1

Sounds good. Maybe the first of these two should also mention that there 
are use cases where text/plain is chosen because the intent *is* to 
display the HTML as plain text, and not render it.

>>   Deploying any heuristic for detecting mistaken Content-Types risks
>>   overriding user intentions and misrepresenting data---accordingly
>>   recipients SHOULD provide for users to disable sniffing in general
>>   and/or in particular cases.
>
> This will make almost all current implementations non-conformant, and I don't have much confidence that they'll become conformant to this requirement any time soon (implementers, I'd love to be proven wrong here).

I don't think that adding a SHOULD here (compared to RFC 2616) will have 
any effect on implementations in practice. Let's rephrase it as advice.

> Also, any thoughts about putting this in Security Considerations instead?

+1 to moving it there.

Best regards, Julian

Received on Wednesday, 19 May 2010 13:39:25 UTC