W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

Re: Call for Adoption: Encrypted Content Encoding

From: Walter H. <Walter.H@mathemainzel.info>
Date: Tue, 01 Dec 2015 10:05:02 +0100
Message-ID: <565D62BE.8090905@mathemainzel.info>
To: Julian Reschke <julian.reschke@gmx.de>
CC: ietf-http-wg@w3.org
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;
> Are you promoting the concept of intercepting proxies that break up 
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 ...

Received on Tuesday, 1 December 2015 09:05:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC