W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Questions about draft-abarth-mime-sniff-00

From: Lisa Dusseault <lisa.dusseault@messagingarchitects.com>
Date: Mon, 6 Apr 2009 09:35:01 -0700
Message-Id: <64498196-B166-428D-9AF8-1C94ED81880C@messagingarchitects.com>
To: Adam Barth <abarth@cs.stanford.edu>
Cc: HTTP Working Group <ietf-http-wg@w3.org>

After talking with people at IETF SFO about the reality of MIME  
sniffing, I got around to reading this draft and considering how to go  
forward with it.  Of course I have a few questions too.

1.  Doesn't the threat model of mime sniffing need to assume that some  
servers are malicious?  the last paragraph of section 1 implies that  
without server cooperation, which implies trusting the server, the  
sniffing procedure can lead to security problems.

2.  "Extensions must not be used for determining resource types for    
resources fetched over HTTP."  why is this a needed requirement?  And  
should there be an exception for IETF Standards Track extensions that  
offer more information on resource types?

3.  Having a fixed table of types with patterns to look for, doesn't  
fully address why we will always have content sniffing: new content  
types are created that servers don't recognize, but a client could be  
updated to recognize.  Should the table simply be a starter set and  
clients can extend at will?  Or is there reason (and a reasonable  
way)  to create an IANA registry for new patterns/types?

4.  Are there any best-practice guidelines for working with users?   
E.g. allowing a user to choose "text/html" for unmarked content might  
be a security hazard.  We don't want specific user interface  
requirements, but this document seems like a good place to extend  
security considerations to getting input from users, if there are such  
guidelines.


Thanks,
Lisa

--- Scanned by M+ Guardian Messaging Firewall ---
Messaging Architects sponsors The Spamhaus Project.
Received on Monday, 6 April 2009 16:35:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:02 GMT