Re: Call for Adoption: Encrypted Content Encoding

> On 2 Dec 2015, at 14:43, Walter H. <Walter.H@mathemainzel.info> wrote:
> 
> On 02.12.2015 14:30, Cory Benfield wrote:
>> (Allow me to quote myself from [1]: “Does this draft raise the risk that my user-agent will automatically execute malware? Sure.”)
> this alone would be reason enough to destroy the draft;

I disagree.

>> What I also said is that it reduces or removes certain other attack surfaces.
> please be concret here, I don't see any reduction or removing of certain other attack surfaces;

Sure. This drastically reduces the likelihood of intermediaries replacing a legitimate payload with a malware-ridden one, on both encrypted (HTTPS) and unencrypted (HTTP) communication channels. For example, it is harder to serve me with a malware-ridden PDF version of my bank statement instead of the one my bank wanted to serve me, because you would need a key I trust in order to do so. (With the enhancements I want to Section 6, you’d need a key that I trust *for this content*, an even higher bar.) This is a legitimate and possible attack that is not possible to mount against communications using this draft.

>> The reason we shouldn’t destroy this draft is because this draft doesn’t “only helps increasing the attack vector”.
> let it me say in other words; I don't see any feature which is new and we hadn't already before …

That cannot be accurate: you’ve just discussed some. Specifically, today I cannot serve you an encrypted image and have it render into your web page without hand-rolling this using Javascript. You cannot serve me a document and cause my browser to notify me that it’s the exact same document I placed on the server three weeks ago. Essentially, this moves a lot of capabilities into my user-agent that previously required custom software or additional steps.

Cory