Re: Call for Adoption: Encrypted Content Encoding

On 30/11/2015 11:42 p.m., John Mattsson wrote:
> 
> 
> On 30/11/15 11:32, "Walter H." <Walter.H@mathemainzel.info> wrote:
> 
>> On 30.11.2015 08:45, John Mattsson wrote:
>>>
>>> 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…
>> I didn't say that these are the only alternative ways, .zip or .rar is
>> just an example;
>> it depends on what you want to encrypt;
>> if for is only something standarized an option, then use the
>> OpenDocument standard;
>> these can be encrypted, too;

By the same logic there is no need to send C-E:gzip on any responses.
Because one can simply deliver .gz files instead of the raw content.


The point of this draft is the same. When anything is encrypted with
intentio that the recipient acts on the decrypted content in ways other
than saving it to a file - the sender emits the appropriate C-E header
that says its crypted (and how). Such that the recipient can decrypt
if/when it has the ability.


>>
>> by the way: the need of this nonsense;
>> because its like open the door and shooting down anybody non-blind who
>> comes in ...
>>
>> use HTTPS ...
> 
> I think this should be used in addition to HTTPS. TLS is not the solution
> to everything. In the WebPush scenario, using only HTTPS would lead to the
> Push Service having access to, and being able to modify the content.
> Content-enryption + HTTPS looks like a good general solution that can be
> used independently of content-type.
> 


HTTPS is point-to-point.

Content-Encoding is truly end-to-end in a way that HTTPS can never
achieve: from uploader to downloader, regardless of what intermediary
action is taking place to optimize the traffic delivery.


Amos

Received on Monday, 30 November 2015 12:23:33 UTC