Subject: [websec] #20: Sniffing should be "opt in" on a case-by-case basis

From: "websec issue tracker" <[email-masked]>
Date: Sun, 23 Oct 2011 23:48:10 -0000

#20: Sniffing should be "opt in" on a case-by-case basis

 The way the document is written as a normative algorithm makes it hard to
 say this, but:

 Every implementation should be free to "opt out" of sniffing based on
 other information it has (previous experience with the site, information
 based on whether a correct MIME type was given vs. misconfigured, etc.)

 From the point of view of a web site, there's no additional security or
 danger from opting out on a case-by-case basis; it's the same as, on a
 case-by-case basis, choosing between two implementations, one of which
 always sniffs and the other never sniffs.

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

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

---

From: Tobias Gondrom <[email-masked]>
Date: Mon, 24 Oct 2011 04:05:58 +0100

<hat="individual">

Agree with this one.
With one addition: it must be clear, that if you "opt-in" for sniffing, 
than you MUST (SHOULD?) follow the mime-sniffing algorithm.

Kind regards, Tobias

---

From: Larry Masinter <[email-masked]>
Date: Sun, 23 Oct 2011 20:26:42 -0700

> Agree with this one.
> With one addition: it must be clear, that if you "opt-in" for sniffing, than you MUST (SHOULD?) follow the mime-sniffing algorithm.

I don't think that's possible. I think the crux of this issue is that I don't think the "mime-sniffing algorithm" is currently structured in a way that lets the results be "opt-in" on a case-by-case basis.  

For example, the algorithm starts with an analysis of existing content-type headers, and winds up, in its state transition and communication paths, not letting later stages of the algorithm know whether the supplied content-type was malformed, whether there were two rather than one, etc.   So if you follow the algorithm, you don't have any way (at least if you're just following this algorithm) of "opting" later in ways that want to distinguish.

---

From: Adam Barth <[email-masked]>
Date: Sun, 23 Oct 2011 20:29:18 -0700

> For example, the algorithm starts with an analysis of existing content-type headers, and winds up, in its state transition and communication paths, not letting later stages of the algorithm know wh…

Sure, but those are things we can fix.  :)

Adam