Subject: [websec] #15: Clarify scope of web sniffing

From: "websec issue tracker" <[email-masked]>
Date: Mon, 17 Oct 2011 21:26:48 -0000

#15: Clarify scope of web sniffing

 This issue may be broken down into several (is X in scope?) but this issue
 is meant to cover the overall question to start with.

 The introduction to the document cites the existence of mis-configured web
 content served via HTTP as the primary justification for "sniffing".

 However, the document itself covers many situations beyond misconfigured
 web content.

 * web sites where content-type values are syntactically correct but
 believed to be different from what was intended (because the content
 itself doesn't match)

 * situations where HTTP protocol content-type is syntactically incorrect,
 duplicate, malformed.

 * situations where no content-type is supplied at all via HTTP.

 * situations where the content is not being delivered via HTTP at all, but
 via other protocols.

 There are a number of these situations, including web accesible material
 delivered via ftp:, file: (on thumb drives?). The internet-draft is
 currently normatively required by a W3C recommendation on zip packaging,
 for example.

 So the basic question is: what is the scope? The "bug" in the
 specification is that the introduction and justification don't match the
 apparent intent of the scope of the body.

-- 
------------------------------+--------------------------------------------
 Reporter:  masinter@…        |      Owner:  draft-ietf-websec-mime-sniff@…
     Type:  defect            |     Status:  new
 Priority:  major             |  Milestone:
Component:  mime-sniff        |    Version:
 Severity:  Active WG         |   Keywords:
  Document                    |
------------------------------+--------------------------------------------

Ticket URL: <http://wiki.tools.ietf.org/wg/websec/trac/ticket/15>
websec <http://tools.ietf.org/websec/>

---

From: "websec issue tracker" <[email-masked]>
Date: Mon, 17 Oct 2011 21:27:32 -0000

#15: Clarify scope of MIME sniffing

-- 
-----------------------------+---------------------------------------------
 Reporter:  masinter@…       |       Owner:  draft-ietf-websec-mime-sniff@…
     Type:  defect           |      Status:  new
 Priority:  major            |   Milestone:
Component:  mime-sniff       |     Version:
 Severity:  Active WG        |  Resolution:
  Document                   |
 Keywords:                   |
-----------------------------+---------------------------------------------

Ticket URL: <http://wiki.tools.ietf.org/wg/websec/trac/ticket/15#comment:1>
websec <http://tools.ietf.org/websec/>

---

From: Tobias Gondrom <[email-masked]>
Date: Wed, 19 Oct 2011 10:39:04 +0100

<hat="individual">

personally I like the scope beyond "http-only".
#1 The mis-configured header website part is in my view the main use case.
But scenarios where no content-type can be transmitted in the header, 
like other protocols (e.g. ftp), filesystem, etc. seem to make sense too.

So in general I would support a broader scope.

Just my 5cents, Tobias

---

From: "websec issue tracker" <[email-masked]>
Date: Sat, 22 Oct 2011 18:45:42 -0000

web content.

 In my view, bullets 1 through 3 arise from misconfigured web servers.

 For bullet 1, there's lots of examples of servers supplying a
 syntactically correct but erroneous MIME type, where I judge the supplied
 MIME type to be erroneous because obeying the MIME type causes the site to
 behave in undesirable ways, e.g., having broken images because the site
 uses a resource as an image but the resource has a Content-Type that says
 text/plain.

 For bullet 2, a syntacticly invalid Content-Type header is manifestly
 caused by a misconfigured server.

 For bullet 3, a correctly configured web server will always supply the
 correct MIME type with a response, but that's just a matter of semantics.

 I'll agree that bullet 4 is a distinct use case and might be valuable to
 point out in the introduction.

Ticket URL: <http://trac.tools.ietf.org/wg/websec/trac/ticket/15#comment:2>
websec <http://tools.ietf.org/websec/>