Re: [websec] Meeting minutes uploaded
Re Mime sniffing, the minutes reported: Nobody in the group objected to having this move to WHAT-WG, and according to Larry Manister, the W3C is also fine with referencing the WHAT-?WG document, so the work item will be removed from our charter. I did not say this. What I said in the meeting was that I had no objection to the working group dropping the work in the IETF. To elaborate: * I think dropping the work is the logical action if none of the implementors are willing to do the work in the IETF. * I do not speak for W3C and what the W3C is Fine with. * However, I believe W3C management is concerned about insuring stable normative references in W3C specs, but they will deal with those. Larry ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] scope of mimesniff: roles vs. contexts vs. delivery channels
Going back to the scope question, should the mimesniff document cover sniffing in contexts other than browsers, e.g., by web servers during file upload, by proxies or firewalls or gateways, by spiders or search engines, etc.? Within the browser context, does it cover sniffing in special applications like font, video, style sheet, script contexts, where more is known about the type that is wanted? The dimension of 'roles' is somewhat orthogonal to the dimension we were talking about previously (whether the specification should cover sniffing of content delivered by means other than HTTP. It seemed that the sentiment previously was to cover a broad scope of delivery channels: sniffing should cover the broad scope of sniffing of content delivered by FTP or through (mounted) file system access, etc., and that the intent was also to cover a broad scope of contexts (including font, video, style sheet, etc.). But what about the other roles? I think we could address them at least to some degree, if only to lay out what the constraints are, or what, say, a firewall should do (scanning content in a firewall should likely scan the data as it might appear in the likely formats that any recipient might interpret the data, for example.) Larry -- http://larry.masinter.net ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] MIME sniffing test suite? Is there one?
I think it would be really helpful to have a test suite for MIME sniffing where we can test out what browsers do and various cases where sniffing *should* improve the experience, as well as test cases where sniffing makes things worse, if there are some. Probably focusing on the test suite would help resolve some of the issues. I'm willing to help populate the test suite but perhaps someone could to put up the infrastructure? Larry ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #21: sniffing of text/html shouldn't override polyglot label of application/xhtml+xml
I don't understand, Philip. A central case of this document involves taking documents that look like text/html but are labeled as text/plain and sniffing them to be text/html after all. It's claimed that this is necessary, part of most browsers today, regular practice, etc. Are you opposed to specifying sniffing from text/plain to text/html? In any case? Larry -Original Message- From: websec-boun...@ietf.org [mailto:websec-boun...@ietf.org] On Behalf Of Philip Gladstone Sent: Monday, October 24, 2011 9:24 AM To: websec@ietf.org Subject: Re: [websec] #21: sniffing of text/html shouldn't override polyglot label of application/xhtml+xml On 10/23/2011 7:52 PM, websec issue tracker wrote: (One still might want to sniff text/html when the type is labeled text/plain, for example, but not for other polyglot cases.) This would be a disaster. For security reasons, a web server needs to know when a document will be executed rather than displayed. Currently, using text/plain will display any document literally. Causing a document that looks like html to be executed will open lots of web sites to XSS. Philip ___ 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
Re: [websec] font sniffing
It's been emphasized that there is no reason why third parties can't register media types if they're wanted. So there should be no barrier to specifying content-type for fonts, if that's what is wanted. Why is it a lost cause when no one even tried? Larry -Original Message- From: websec-boun...@ietf.org [mailto:websec-boun...@ietf.org] On Behalf Of Anne van Kesteren Sent: Monday, October 24, 2011 4:44 AM To: Tobias Gondrom Cc: websec@ietf.org Subject: Re: [websec] font sniffing On Mon, 24 Oct 2011 20:36:50 +0900, Tobias Gondrom tobias.gond...@gondrom.org wrote: So a specific use case for this could be helpful - and a volunteer to provide input on by which criteria exactly fonts should be sniffed and help with writing up the font mime-type for the registry (I can help with the latter). The use case is @font-face, CSS' font linking feature. The criteria I have emailed to this list before: http://www.ietf.org/mail-archive/web/websec/current/msg00235.html -- Anne van Kesteren http://annevankesteren.nl/ ___ 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
Re: [websec] Are all the issues filed? (was: Re: Using IETF Tracker for issues on MIME sniffing?)
I'd meant to do more careful write-ups of the issues I put into the tracker, but I've put in the main issues left over from draft-masinter-mime-sniff. The document also contains several sections (on sniffing fonts, for example) which are left as TBD. I suppose each of those is a separate issue to fill out. Larry ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #19: Do not sniff PDF
- in which way is it more certain that there is no mislabeled PDF than a mislabeled jpg or mislabeled rtf? I don't think this is relevant. There is likely mislabeled PDF. But I had specific feedback from implementors of PDF readers that sniffing from other content-type resulted in a worse situation than not sniffing. I don't have any information on jpg or rtf. Sniffing should only be done when it is justified by an improved user experience over not sniffing. I think the obligation of evidence is opt in: we should only sniff content when there is evidence of mislabeled content for which sniffing actually improves something, and the improvement outweighs other considerations. - what about scenarios in which there is no content-type (e.g. ftp, filesystem), should in this case sniffing not be done? I didn't get any feedback on that. I don't know any workflows where valid PDF doesn't carry a file type label somehow (if only the file extension .pdf), so maybe sniffing based on file content itself doesn't matter. ((Maybe this is another issue? I just wonder if the algorithm for no content-type is the same, needs to be the same, as the algorithm for content-type via HTTP.) Larry ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #20: Sniffing should be opt in on a case-by-case basis
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. ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #22: content-type sniffing should include charset sniffing
First you determine the content-type and then after that you may want to determine the charset used within that content-type That's wishful thinking that doesn't match what has to happen ... the mime-sniffing document ALREADY is looking at the charset, by looking for byte-order-mark signatures to decide whether the content is text or binary. So we're already doing charset detection, just not calling it that or completely specifying it. ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
