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

Re: Call for Adoption: Encrypted Content Encoding

From: Cory Benfield <cory@lukasa.co.uk>
Date: Wed, 2 Dec 2015 15:04:48 +0000
Cc: ietf-http-wg@w3.org
Message-Id: <D136ED4D-607E-4A0B-A7EA-85E596F56BC0@lukasa.co.uk>
To: "Walter H." <Walter.H@mathemainzel.info>

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


Received on Wednesday, 2 December 2015 15:05:25 UTC

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