Re: [websec] #19: Do not sniff PDF

2011-10-24 Thread Julian Reschke 

On 2011-10-24 10:17, Tobias Gondrom wrote:

...

((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".)


I can imagine that the cases "no content-type given" and "wrong
content-type given" could be treated differently, but I am not sure
about it.
...


If you can define "wrong content-type" :-)
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #19: Do not sniff PDF

2011-10-24 Thread Tobias Gondrom 

On 24/10/11 04:21, Larry Masinter wrote:

- 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.


Fine by me. The browsers and OS started sniffing for exactly that reason 
in the first place, to improve user experience.


The reason why I am asking so specifically about the reasons for not 
doing PDF sniffing is the following:
In general I can imagine a number of scenarios where sniffing is 
disadvantageous (i.e. leads to security risks) for certain file types. 
The main threat with sniffing is it leads to false-positives being 
thrown into the application. Yet, it seems the browser vendors do so 
anyway - Which led us do this draft in the first place.


If we exclude one specific file-type from sniffing, there are two 
interesting points:
1. we should have a compelling explanation for the browsers/OS not to do 
so, so they will follow the RFC.
2. these reasons may likely also be true for other file-types. So 
looking at them, we might deduce that they hold true for other 
content-types as well. Which again would be very useful information.




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".)


I can imagine that the cases "no content-type given" and "wrong 
content-type given" could be treated differently, but I am not sure 
about it.







Larry



___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #19: Do not sniff PDF

2011-10-23 Thread Adam Barth 
On Sun, Oct 23, 2011 at 8:21 PM, Larry Masinter  wrote:
>> - 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.

That seems very anecdotal.  Do you have data to back up these claims?

Adam
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #19: Do not sniff PDF

2011-10-23 Thread Larry Masinter 
> - 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] #19: Do not sniff PDF

2011-10-23 Thread Tobias Gondrom 


Am not sure I understand this issue:
- in which way is it more certain that there is no mislabeled PDF than a 
mislabeled jpg or mislabeled rtf?
- what about scenarios in which there is no content-type (e.g. ftp, 
filesystem), should in this case sniffing not be done?


Kind regards, Tobias



On 24/10/11 00:43, websec issue tracker wrote:

#19: Do not sniff PDF

  There should be a strong advice not to sniff PDF -- if the data is
  mislabeled as something else, then sending it to a PDF interpreter is
  likely just an error.



___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

[websec] #19: Do not sniff PDF

2011-10-23 Thread websec issue tracker 
#19: Do not sniff PDF

 There should be a strong advice not to sniff PDF -- if the data is
 mislabeled as something else, then sending it to a PDF interpreter is
 likely just an error.

-- 
+
 Reporter:  masinter@…  |  Owner:  draft-ietf-websec-mime-sniff@…
 Type:  defect  | Status:  new
 Priority:  minor   |  Milestone:
Component:  mime-sniff  |Version:
 Severity:  -   |   Keywords:
+

Ticket URL: 
websec 

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec