Re: Call for Adoption: Encrypted Content Encoding

On 02.12.2015 11:16, Cory Benfield wrote:
>> On 1 Dec 2015, at 20:12, Walter H.<Walter.H@mathemainzel.info>  wrote:
>>
>> On 01.12.2015 16:14, Amos Jeffries wrote:
>>> The question was how is encrypting using file-based methods safer than
>>> encryption with this draft method. My conclusion: it is not.
>> file-based methods won't get decrypted automatically without any mechanism on client side;
>> this draft method does.
> You’re right: without this draft the file-based methods won’t get decrypted, no. It’s worse: they get *executed*.
you are talking about content, this draft has no influence, because it 
is not encrypted;

lets talk about the following case:

someone places somewhere an IMG-HTML-Tag

and would you really tell me, that in case this IMG-HTML-Tag points to 
such an encrypted file, this
will never be shown/executed/what ever?

as I said, in case the UA has no knowledge about this draft, nothing 
happens;
but with knowledge of this draft, you can't tell me that the encrypted 
content won't be shown;

to bring you notice the difference:

without this draft: someone has to explicitly a .js, .vbs, ... in the 
HTML-Tag or the server MUST send the
MIME type for the content in case it is .jpeg or other not harmful;
and this can be filtered easily;

with this draft there doesn't not exist any way of filtering it; because 
the URL looks as it should, but the content is something different;

in case you use a proxy, then with this draft, the proxy can't filter 
anything; without, it can;

> Decryption itself should not be a malware distribution vector. The only way it could be is if the decryption code itself is vulnerable to a code injection attack of some form (e.g. buffer overflow). That’s certainly *possible*, but it’s not standard practice.
>
> However, user-agents automatically process plenty of file formats already.
yes but without this draft they can't do anything in case the content is 
encrypted ...
with this draft, the HTTP request tells the server to hand out all 
neccessary and the malware is on your client ...

did you understand?


>   Chrome opens PDFs in an internal renderer: PDFs are a potential malware distribution vector.
only when opened with adobe; not every piece of software does the same 
stupid things ...


>   Internet Explorer can be configured to helpfully open whatever program is associated with a file format without user input.
IE is only on windows; and with Win10 Edge is MS's answer of Google's 
Chrome

>   Safari will automatically decompress a ZIP file that it’s served.
yes but then this draft makes it; we didn't talk about unencrypted 
content ...

> If user-agents did not execute, but did transparently decrypt, all content, there would be no problem. The problem is trusting the decrypted content, and that risk already exists for the non-decrypted content you receive today.
you are right: "If user-agents ...", then this draft raises the risks, 
because not only decrypted content is a problem, also encrypted content ...
>   Plus, when I download a zip file from GitHub today, there’s no guaranteeing that a MITM box didn’t replace that zip file with one containing a malware-based payload. This new draft does provide me with that guarantee: only GitHub and I can tamper with that file.
nobody did say this;
>
> Once again, I cannot stress this enough: this draft does not add any new malware distribution vector.
think of the example above and your stressing is against walls of water ...


>   It makes certain malware distribution vectors harder to use, and it makes certain malware detection methods potentially less effective.
this is nonsense ... see above ...