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

From: [email-masked] (Henry S. Thompson)
Date: Sun, 21 Mar 2010 20:02:55 +0000

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.
- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
                         Half-time member of W3C Team
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]

---

From: Yves Lafon <[email-masked]>
Date: Wed, 24 Mar 2010 20:17:47 -0400 (EDT)

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

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mark Nottingham writes:
>

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.

   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

---

From: David Morris <[email-masked]>
Date: Wed, 24 Mar 2010 17:37:58 -0700 (PDT)

>   Such recipients SHOULD NOT override the specified type it there are
                                                    wrong ^^^^ word

>   heuristic Content-Type detection.

Nice artistic avoidance of the sniffword... I have no objection providing
'it' doesn't become something I haven't tried in context.

Dave Morris