Re: Call for Adoption: Encrypted Content Encoding

On 01.12.2015 09:33, Cory Benfield wrote:
>> On 1 Dec 2015, at 08:22, Walter H.<Walter.H@mathemainzel.info>  wrote:
>>
>>> The browser will build a end to end TLS tunnel through known proxies. Intercepting proxies may do MITM and
>> and exact these intercepting proxies can't validate this content, if it contains malware or not;
>> as I said, THIS DRAFT IS NONSENS;
>
> It’s not at all clear to me how this objection applies.
encrypted content, that is spreaded to the wide this way without the 
real knowlegde where it really does come ...
>   The purpose of encrypting the content is to prevent it being read by intermediaries. That’s literally what encryption is for.
only if it is not done this way, because with this draft, no server at 
all can decrypt this content, and the primary source isn't known, too;
> If an intermediary is worried that a client may be downloading malware in an encrypted body, it can simply chose to refuse to forward the response, and instead send some 4XX/5XX code.
without this draft this situation would not exist ...
> This is actually *easier* with this draft than it was before because the intermediary can reliably identify encrypted payloads and choose to block them, without needing to introspect the payload very closely.
no, this draft raises other security problems;