Re: Call for Adoption: Encrypted Content Encoding

On 01.12.2015 09:33, Julian Reschke wrote:
> On 2015-12-01 09:22, Walter H. wrote:
>> On 01.12.2015 01:19, Roland Zink wrote:
>>> Am 01.12.2015 um 00:32 schrieb Jim Manico:
>>>> > TLS is also end-to-end
>>>>
>>>> No way is that true. TLS per the standard can be MITM'ed by proxies
>>>> in ways that subvert both certificate pinning and HSTS in ways that
>>>> do NOT inform the user in any browser today. I'm happy to provide
>>>> references to this if you like.
>>>>
>>> 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;
>
> Are you promoting the concept of intercepting proxies that break up 
> HTTPS?
not really, this concept will come more and more as a weapon againt 
paranoia that
everything "must" be HTTPS
>
>>> RFC7469 says it is allowed for clients to turn off pin validation
>>> based on some policy and still be compliant. Is this what you want to
>>> reference?
>>>
>>> However it is also compliant to not do this and do pin validation.
>>>
>> what does this help preventing clients receiving malware, that will be
>> raised through this draft?
>
> Privacy and the ability for third-parties to inspect the contents 
> obviously are conflicting goals. Nothing new here.
>
and why DOES someone really want to promote something (THIS) to a 
standard, which
raises these problems?
> One reason for the use of encrypted content in a "blind cache" is to 
> allow caching of HTTPS content without having to mount a MITM attack. 
this draft is in connection with HTTP not HTTPS
> And I believe that's a very good reason.
>
not  really,
dynamic content is not cacheable and static content - at these times 
rearely to find - needn't be HTTPS ...