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

Re: Call for Adoption: Encrypted Content Encoding

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 1 Dec 2015 09:33:47 +0100
To: "Walter H." <Walter.H@mathemainzel.info>, Roland Zink <roland@zinks.de>
Cc: Jim Manico <jim@manicode.com>, ietf-http-wg@w3.org
Message-ID: <565D5B6B.5050007@gmx.de>
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?

>> 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.

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. 
And I believe that's a very good reason.


Best regards, Julian
Received on Tuesday, 1 December 2015 08:34:19 UTC

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