Re: Call for Adoption: Encrypted Content Encoding

On 01.12.2015 16:14, Amos Jeffries wrote:
> The question was how is encrypting using file-based methods safer than
> encryption with this draft method. My conclusion: it is not.
file-based methods won't get decrypted automatically without any 
mechanism on client side;
this draft method does.

I didn't find any example of how the HTTP request looks like, only the 
Responses as in chapter 5

so there are two possibilities

the client has implement this draft and stores the decrypted content, 
and if it is "useful" runs it ..., the worst case
or the client doesn't know this draft and also doesn't know what to do 
with the extra fields in the HTTP response ...

at todays view it would be good not to update the client ...

>> just the same as raw content;
>> if they are encrypted they won't be any dangerous, because no key, means
>> no access;
>> but for this proposal, the server has no change doing anything against,
>> and at client side,
>> the malware may get start automatically, because of raw Content-Type ...
>>
> There is the attack vector that needs addressing. BUT exactly that, it
> needs addressing; not throw-the-whole-draft-away nor throw-privacy-away.
before giving potential attackers another possibility how they can 
attack more efficient,
it is better to throw away this draft, and think of, what went wrong ...
> The first step in mitigation is that the crypto needs to be stripped
> away for the auto-execute to actually work. Which as Cory mentioned
> already requires the victim to have a key. See above for the two key
> cases from server perspective.
are you sure that there is no mechanism, to download the content and get 
it decrypted native?
just think of the HTTP header that is needed to get the content ...
>
> To be honest the malware I'm aware of was encrypted .chm and .exe
and what were these encryption formats?
I mean I can pack any file into an archive format and encrypt this ...