Re: Call for Adoption: Encrypted Content Encoding

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.
> 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.
>
> Eliot
>
>
Regards,
Roland

Received on Monday, 30 November 2015 11:50:39 UTC