W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

Re: Call for Adoption: Encrypted Content Encoding

From: Walter H. <Walter.H@mathemainzel.info>
Date: Wed, 02 Dec 2015 13:56:59 +0100
Message-ID: <565EEA9B.9080609@mathemainzel.info>
To: Cory Benfield <cory@lukasa.co.uk>
CC: ietf-http-wg@w3.org
On 02.12.2015 13:23, Cory Benfield wrote:
>> 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.
that is wrong; it will, no chance to stop it before ...
>   In fact, I said the exact opposite: it will definitely get ‘executed’
and will raise the attack vector, which you lie about ...
>> 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.
that is wrong, not every user agents accesses the server direct; all 
user agents using proxies or similar might not get the chance to 
'execute' that image file - with this draft they do;
and so you are really telling me this draft doesn't increase the attack 
>   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.
then tell me why?

as long as this draft only helps increasing the attack vector it must be 
destroyed and thought of better ways ...

Received on Wednesday, 2 December 2015 12:57:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC