Re: Call for Adoption: Encrypted Content Encoding

> On 2 Dec 2015, at 12:56, Walter H. <Walter.H@mathemainzel.info> wrote:
> 
> On 02.12.2015 13:23, Cory Benfield wrote:
>> 
>>> 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 …

I’m sorry, here is a simple miscommunication. When I said “No, of course not”, I was answering your question. Your question was: “Would I tell you that an encrypted image will never get shown?” My response was “I am not saying that.” More specifically: of *course* that image will get shown, that’s the point. We’re agreeing here.

Please don’t call me a liar. There’s no reason for this discussion to get personal.

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

No, I’m not telling you that. In fact, as I said multiple times in this discussion (in [0], and [1], which is literally the email you’re replying to), I said that it absolutely *does* increase the attack vector *for this particular attack*.

(Allow me to quote myself from [1]: “Does this draft raise the risk that my user-agent will automatically execute malware? Sure.”)

What I also said is that it reduces or removes certain other attack surfaces. These two things can be simultaneously true (and in fact, I am arguing that they are).

I’m sorry that I’ve been insufficiently clear on this point.

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

The reason we shouldn’t destroy this draft is because this draft doesn’t “only helps increasing the attack vector”. It increases one particular attack vector, closes off others, and also introduces the valuable ability to more-easily secure a communication from all intermediary parties. This ability is important and useful, and making it available is important. I believe that the risk you highlight exists, and should be acknowledged in Section 6 of the draft.

However, I think that the draft should progress with that note in place, because I do not believe that you could introduce this kind of secure communication without increasing the risk of malware injection. It is my opinion that what we gain from this draft is more than what we lose.

Cory

[0]: https://lists.w3.org/Archives/Public/ietf-http-wg/2015OctDec/0287.html
[1]: https://lists.w3.org/Archives/Public/ietf-http-wg/2015OctDec/0305.html