[websec] draft-ietf-websec-mime-sniff - questions

[Tobias Gondrom <[e-mail]>]

Hello Adam, hello fellow websec members,

thanks a lot for the new version.
Just been reading through your draft again and have a few questions and
comments (as an individual, not in my WG chair role):

0. unfortunately don't know too much about video format sniffing, so
hope someone else can help with MP3 and H.264?

1. in section 2, page 5: a note states: "If an HTTP response contains
multiple Content-Type header fields, the user agent MUST use the
textually last Content-Type header field to the official-type.For
example, if the last Content-Type header field contains the value "foo",
then there is no official media type because "foo" cannot be interpreted
as a media type (even if the HTTP response contains another Content-Type
header field that could be interpreted as a media type)."
Question: Does this derive from a requirement in RFC2616 or is this your
recommendation and if the latter why can't a user agent use a
content-type he supports?


2. And regarding Mime-sniffing when a content-type is set:
Although rfc2616 states that mime-types may only be guessed by a
recipient, do you know whether common browser implementations guess the
mime-type even when the content-type is given (I believe to remember to
have run into this in some windows scenarios when the browser read the
content-type and handed the data over to the OS for display and the OS
then determined a different media-type (using magic numbers,
filename-extensions, etc.) and again opened a totally different
application. Are you aware whether this is still true?
(RFC2616, section 7.2.1 "Any HTTP/1.1 message containing an entity-body
SHOULD include a Content-Type header field defining the media type of
that body. If and only if the media type is not given by a Content-Type
field, the recipient MAY attempt to guess the media type via inspection
of its content and/or the name extension(s) of the URI used to identify
the resource. If the media type remains unknown, the recipient SHOULD
treat it as type "application/octet-stream".")


3. In section 5 I noticed that you classified postscript as "safe".
Am not sure whether this problem still exists, but I recall an instance
a few years back when I actually saw an attack using a postscript file,
that contained a script that would be executed on the server when the
file was rendered by a postscript library to another format (e.g. the
script then kicked in and started printing s.th.)
This flaw may not have been due to postscript, but only due to the
library, but am not sure that postscript specification doesn't contain
any scriptable content (file operations, printing) anymore?


and some more strategic questions:
4. What do you think, should we consider that a server be able to
declare in the http header that the client "MUST not" use mime-sniffing
and by this enforce a stricter mime-identification policy at the client?

5. And on another note, how do you think about different levels of
strictness (either to be set in the client and/or in the server (http
header): for example to illustrate this more, three levels:
a) disable mime-sniffing,
b) conservative mime-identification,
c) flexible mime identification.

6. and maybe stupid question:
In section 6: Why does svg+xml get a special treatment?
("If the official-type is "image/svg+xml", then let the sniffed-type be
the official-type (an XML type) and abort these steps.")

Many greetings

Tobias



On 01/24/2011 10:35 PM, Adam Barth wrote:
> Websecians,
>
> I've uploaded a new draft of draft-ietf-websec-mime-sniff that
> contains a handful of signatures for video and audio types supported
> by web browsers:
>
> http://www.ietf.org/id/draft-ietf-websec-mime-sniff-01.txt
>
> I've been trying to avoid getting embroiled in the video/audio format
> mess, but several folks have asked me to add this information to the
> document so that browsers can improve their interoperability.
>
> As you can see, I've added WebP, Ogg, WAVE, and WebM:
>
> http://tools.ietf.org//rfcdiff?url1=http%3A//www.ietf.org/id/draft-ietf-websec-mime-sniff-00.txt&url2=http%3A//www.ietf.org/id/draft-ietf-websec-mime-sniff-01.txt
>
> I would like to add MP3 and H.264 as well, but I'm unsure which
> signatures to use.  If you know which signatures we should use for
> these formats, please let me know.  Also, note that
> http://www.w3.org/html/wg/wiki/ChangeProposals/NoVideoContentType will
> likely have an effect on how we'll want to treat sniffing video,
> depending on whether that change proposal prevails.
>
> Thanks,
> Adam
> _______________________________________________
> websec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/websec