Re: content inspection in absence of media type, was: [apps-discuss] APPSDIR review of draft-ietf-httpbis-p2-semantics-24

On 2013-10-29 14:26, S Moonesamy wrote:
> Hi Julian,
> At 09:06 28-10-2013, Julian Reschke wrote:
>> On 2013-10-28 09:07, S Moonesamy wrote:
>> (which expired ~2 years ago)
>
> I guess that the working group gave up.  Please note that I did not
> suggest adding a reference.
>
>> Could you clarify what exactly the issue is?
>>
>> RFC 2616 said
>> (<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.7.2.1.p.4>):
>>
>>> 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".
>>
>> ...which isn't that different.
>
> The 'If the media type remains unknown, the recipient SHOULD treat it as
> type "application/octet-stream' from RFC 2616 is not in
> draft-ietf-httpbis-p2-semantics-24.

I consider that sentence to be useless - if I can't detect the type, 
what else but "treating as arbitrary data" is left as an option anyway?

> The issue is the "or examine the data to determine its type".  I'll
> comment about the text (Section 3.1.1.5) again.  The server has to
> generate a Content-Type header field unless the media type is unknown.

Yes.

> There is then a RFC 2119 "may" which is applicable when the (previous)
> RFC 2119 "should" cannot be applied.  My reading of the "may" is that
> the usage is not entirely correct.  I am not raising that as an issue.

I still don't get what the issue is :-)

> The issue is whether there is a security problem and whether there is
> adequate discussion of it (e.g. it is discussed in a Security
> Considerations section).

The subsequent text is:

"In practice, resource owners do not always properly configure their 
origin server to provide the correct Content-Type for a given 
representation, with the result that some clients will examine a 
payload's content and override the specified type. Clients that do so 
risk drawing incorrect conclusions, which might expose additional 
security risks (e.g., "privilege escalation"). Furthermore, it is 
impossible to determine the sender's intent by examining the data 
format: many data formats match multiple media types that differ only in 
processing semantics. Implementers are encouraged to provide a means of 
disabling such "content sniffing" when it is used."

Do you think this is insufficient, or that it needs to move to a 
different part of the spec?

Best regards, Julian

Received on Tuesday, 29 October 2013 14:13:02 UTC