- From: Lisa Dusseault <lisa.dusseault@messagingarchitects.com>
- Date: Mon, 6 Apr 2009 09:35:01 -0700
- 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 UTC