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

Re: Call for Adoption: Encrypted Content Encoding

From: John Mattsson <john.mattsson@ericsson.com>
Date: Mon, 30 Nov 2015 07:45:13 +0000
To: Walter H. <Walter.H@mathemainzel.info>, Martin Thomson <martin.thomson@gmail.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <D281BA29.419A9%john.mattsson@ericsson.com>


On 29/11/15 11:20, "Walter H." <Walter.H@mathemainzel.info> wrote:

>On 28.11.2015 03:43, Martin Thomson wrote:
>> On 26 November 2015 at 20:48, Walter H.<Walter.H@mathemainzel.info>
>>wrote:
>>> can someone tell me REAL USEFUL use case where someone would need
>>> this way of having something encrypted on a webserver?
>>
>> The two use cases where this is likely to appear in the short term are:
>>
>> 1. web push - where an encrypted resource is created on a server by
>> one entity and retrieved by another.  The server doesn't get to see
>> the contents.
>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 ...

Using .rar or .zip for encryption is not an option. Not only are they
proprietary, non-standardized compression algorithms, the encryption parts
are based on passwords and at least the .zip encryption is seriously
flawed…

>
>> 2. blind caching - the same as in web push actually.  An origin server
>> uses an untrusted cache and wants to encrypt data so that the cache
>> can't modify or view the content.
>as I think this is a security hole, too.
>
>now where is a REAL USEFUL use case?
>
>


Received on Monday, 30 November 2015 07:45:47 UTC

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