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

On Sun, 21 Mar 2010, Henry S. Thompson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mark Nottingham writes:
>
>> As you may know, the WG has already extensively discussed Content
>> Sniffing, in
>> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/155>, and we
>> thought we were in a position to consider the issue closed.
>
> Indeed we are aware of that.
>
>> The discussions leading up to the current text were voluminous
>> (search the mail archives for messages with a subject including
>> "155" and/or "sniff"), so while we can certainly talk about adding
>> more, I'm reluctant to do so unless we get good review. In
>> particular, has the TAG coordinated this proposal with the HTML5 WG?
>
> Sorry to be slow in replying, and we certainly understand that
> re-opening closed issues is not to be requested lightly, but the TAG
> is very concerned about the security and architectural implications of
> the current draft, and feels that it is important that these are
> called out.
>
> Please note that we are _not_ asking you to reference any other
> discussion of sniffing.  Nor do we challenge the basic thrust of this
> section, which leaves the final decision about sniffing outside your
> spec.  In particular we do not believe the proposed changes are
> inconsistent with anything the HTML5 spec. currently says or the HTML
> WG intends.
>
> What we are asking is that the spec. not be silent about the _risks_
> of sniffing, or of what it really means.
>
> I've included public-html to this discussion, per your request, and
> repeated the suggested amendment below for their information.
>
> ht, by and on behalf of the TAG (ref ACTION-370)
> ========
> Suggested addition to the end of section 3.2.1 of Part 3 of HTTP bis [1]:
>
>  If the Content-Type header field _is_ present, a receipient which
>  interprets the underlying data in a way inconsistent with the
>  specified media type risks drawing incorrect conclusions.
>
>  In practice, however, currently-deployed servers sometime provide a
>  Content-Type header which does not correctly identify the content
>  sent, with the result that some classes of recipients have adopted a
>  policy of examining the content and overriding the specified type.
>
>  Such 'sniffing' SHOULD NOT be done unless there is evidence that the
>  specified media type is in error (for example, because it is
>  'text/plain' but there are bytes in the data which are not legal for
>  the specified or defaulted charset).  In any case recipients SHOULD
>  NOT override the specified type if the change would significantly
>  increase the security exposure ('privilege escalation').
>
>  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.

Since the main point is about warning people about the security 
implication of media type 'sniffing', it would make more sense to put this 
text in the security section of part 3.

Would you agree with the following (slighylt amended) text being put as 
section 7.3
<<
7.3 Media Type Issue

   If the Content-Type header field is present, a recipient which
   interprets the underlying data in a way inconsistent with the
   specified media type risks drawing incorrect conclusions.

   In practice, however, currently-deployed servers sometime provide a
   Content-Type header which does not correctly identify the content
   sent, with the result that some classes of recipients have adopted a
   policy of examining the content and overriding the specified type.

   Deploying any heuristic for detecting mistaken Content-Types risks
   overriding user intentions and misrepresenting data. It may also
   significantly increase the security exposure ('privilege escalation');
   Such recipients SHOULD NOT override the specified type it there are
   known security risks and they SHOULD provide for users to disable such
   heuristic Content-Type detection.
>>>

Cheers,

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Thursday, 25 March 2010 00:18:02 UTC