Re: [websec] #15: Clarify scope of MIME sniffing

2011-10-22 Thread websec issue tracker
#15: Clarify scope of MIME sniffing


Comment (by ietf@…):

  However, the document itself covers many situations beyond misconfigured
 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.

-- 
-+-
 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://trac.tools.ietf.org/wg/websec/trac/ticket/15#comment:2
websec http://tools.ietf.org/websec/

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec


Re: [websec] #16: lack of explanatory text and no justifications for the normative language

2011-10-22 Thread websec issue tracker
#16: lack of explanatory text and no justifications for the normative language


Comment (by ietf@…):

 There's a lot of discussion of the rationale in this document:

 http://www.adambarth.com/papers/2009/barth-caballero-song.pdf

 I'm not opposed to importing that information into this document.

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

Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/16#comment:1
websec http://tools.ietf.org/websec/

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec


[websec] Are all the issues filed? (was: Re: Using IETF Tracker for issues on MIME sniffing?)

2011-10-22 Thread Adam Barth
Larry,

Have you filed all the issues you'd like addressed?  I went though the
issue tracker and I only found two:

http://wiki.tools.ietf.org/wg/websec/trac/ticket/15
http://wiki.tools.ietf.org/wg/websec/trac/ticket/16

Below you mention nosniff, but I don't see that in the issue
tracker.  Please let me know when you've finished filing the issues
you care about.

Adam


On Sat, Oct 15, 2011 at 4:52 PM, Larry Masinter masin...@adobe.com wrote:
 Could we start using the IETF tracker to keep track of our conversation on 
 the issues on MIME sniffing?

 The interaction with a nosniff header should be one issue.
 The other three big issues that come to mind are

 *  scope (do what situations does this apply)
  * opt-in case-by-case (whether one either sniffs ALWAYS or sniffs NEVER, 
 or whether it's more nuanced and based on expectation)
 * normative algorithm vs. invariants for specifications.


 I'm willing to write up these issues and the sniffing ones from 
 http://tools.ietf.org/html/draft-masinter-mime-web-info , and I hope we can 
 capture Pete Resnick's issues as well as Alexey's.

 Larry


 -Original Message-
 From: websec-boun...@ietf.org [mailto:websec-boun...@ietf.org] On Behalf Of 
 Tobias Gondrom
 Sent: Sunday, October 02, 2011 2:44 PM
 To: hal...@gmail.com
 Cc: websec@ietf.org
 Subject: Re: [websec] I-D Action:draft-ietf-websec-mime-sniff-03.txt
 Importance: Low

 hat=individual
 Whether browser will implement it, can't tell. Maybe we can learn more when 
 we progress further with the mime-sniff draft.

 I don't have a strong opinion on the nosniff header.
 Depending on where the mime-sniff debate will lead us, it might be a way to 
 mitigate concerns that in certain cases you really SHOULD NOT or MUST NOT 
 (RFC2119) sniff. Well and with such a header you could enforce exactly that 
 for your sources, without breaking other unknown things/sites - which is the 
 main reason for many browser vendors to start do sniffing in the first place.
 (in one way nosniff could even be a migration path to less sniffing)

 Best regards, Tobias



 On 01/10/11 15:30, Phillip Hallam-Baker wrote:
 On Sat, Oct 1, 2011 at 2:47 AM, Adam Barthi...@adambarth.com  wrote:
 On Fri, Sep 30, 2011 at 10:14 PM, Martin J. Dürst
 due...@it.aoyama.ac.jp  wrote:
 On 2011/09/29 11:45, Adam Barth wrote:
 On Wed, Sep 28, 2011 at 5:44 PM, Martin J. Dürst
 due...@it.aoyama.ac.jp    wrote:
 On 2011/09/29 8:26, Adam Barth wrote:
 As I recall, the nosniff directive is pretty controversial.
 But then, as I recall, the whole business of sniffing is pretty
 controversial to start with. Are there differences between the
 controversiality of sniffing as such and the controversiality of
 the nosniff directive that explain why one is in the draft and the
 other is not?
 The reason why one is in and the other isn't is just historical.
 nosniff didn't exist at the time the document was originally written.
 Your first answer sounded as if the nosniff directive was too
 controversial to be included in any draft, but your second answer
 seems to suggest that it was left out by (historical) accident, and
 that it might be worth to include it.
 The essential question isn't whether we should include it in the
 draft.  The essential question is whether folks want to implement it.
 If no one wants to implement it, putting it in the draft is a
 negative.  If folks want to implement, then we can deal with the
 controversy.
 +1

 The controversy seems to be of the 'cut off nose to spite face'
 variety. Sniffing is definitely terrible from a security perspective
 but people do it. Java and Java Script were terrible as well but
 people did them and then left the rest of us with a mess that had to
 be fixed slowly over then next ten years.

 Sure this is not something we should have to think about but the fact
 is that the browsers do it and it is better for the standards to
 describe what the browsers actually do than what people think they
 should do.



 ___
 websec mailing list
 websec@ietf.org
 https://www.ietf.org/mailman/listinfo/websec
 ___
 websec mailing list
 websec@ietf.org
 https://www.ietf.org/mailman/listinfo/websec

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec