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

Re: Call for Adoption: Encrypted Content Encoding

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Tue, 1 Dec 2015 01:33:27 +1300
To: ietf-http-wg@w3.org
Message-ID: <565C4217.2010600@treenet.co.nz>
On 1/12/2015 12:50 a.m., Roland Zink wrote:
> Am 30.11.2015 um 12:06 schrieb Eliot Lear:
>> Hi,
>> On 11/29/15 11:20 AM, Walter H. wrote:
>>> I'd say this is the wrong answer, this can be done alternativly as
>>> used to do
>>> (pushing an encrypted .rar or .zip is exactly this use case with
>>> advantage,
>>> there is no implicit malware impact ...)
>>> for security reason exactly this way you mentioned must be forbidden;
>>> there mustn't be a way pushing malware to a server,
>>> which the server itself has no possibility to clean it ...
>> I have to agree that this is a big issue.  Here's the problem: we like
>> to say that we would devolve the responsibility to the end user who is
>> pushing the file.  The problem occurs when the end user who is pushing
>> the file has been broken into and her credentials have been stolen.
>> That's the classic BOTnet model.  And so this poses a new vector that
>> wasn't there before.

> How is this different from the current web model allowing ads to be
> served from everywhere? There is no guarantee that the content can't be
> hijacked.

Also how is this different from malware infected machines uploading
encrypted payloads today?

IMHO those opaque encrypted .rar/.zip files are a more fertile and
safe-from-inspection vector for malware to be using than this proposal
where the raw Content-Type etc are exposed for vetting.

>> But I would suggest that there are mitigations to this attack, one such
>> being that the content is attested to by a malware protection system
>> (McAfee, Kaspersky, etc) such that server might trust it, and might
>> otherwise reject such content.

> Do you want to allow third parties access to the content?

>> In as much as we can have the discussion as to how to mitigate the
>> attack, I'm +1 for adopting.  Otherwise -1.

Mitigate in the same ways that transferring encrypted files over
HTTP/FTP/gopher/etc right now are handled. I.e. this is not a new vector.

Received on Monday, 30 November 2015 12:34:30 UTC

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