Re: Call for Adoption: Encrypted Content Encoding

> On 2 Dec 2015, at 11:32, Walter H. <Walter.H@mathemainzel.info> wrote:
> 
> 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?

No, of course not. In fact, I said the exact opposite: it will definitely get ‘executed’ (I’m using ‘execute’ here very broadly, but it saves us having to fight too much about what the correct word is for each type).

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

Yes, but that’s no different to right now. If I put a HTML <img> tag in my web page right now, *all* user agents will ‘execute’ that image file. But this isn’t new to encryption: the only new thing is that your proxy can’t decide my user-agent shouldn’t execute something.

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

Yes, that’s correct. But as I’ve said before, that’s not a reason to destroy this draft. It’s a note worth putting in Section 6 of this draft, sure, but it’s not at all unreasonable to want to guarantee the integrity and privacy of a transmission. After all, while your proxy may only filter things for my “safety”, someone else's proxy may replace the legitimate content I wanted with other, potentially malicious, content. One person’s legitimate use case is another person’s active attack vector.

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

You said, this, which I understand, but then you said this:


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

Reconciling these two things is tricky. Your concern is that the client will automatically execute the encrypted content, but then you rubbished my concerns about this being an attack vector. My point is that the risk is not in decrypting content, it’s in running that content. Does this draft raise the risk that my user-agent will automatically execute malware? Sure. But I view that as a problem that user-agents should address when implementing this draft. Not a reason to remove the draft altogether.

Cory