W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: multiplexing -- don't do it

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Tue, 3 Apr 2012 01:27:36 +0200
Message-ID: <CAA4WUYjnhFecyqze3U2cT+4UDkPj_qf45P0W3agcyBwSht+ONg@mail.gmail.com>
To: patrick mcmanus <pmcmanus@mozilla.com>
Cc: ietf-http-wg@w3.org
On Tue, Apr 3, 2012 at 1:21 AM, patrick mcmanus <pmcmanus@mozilla.com>wrote:

> On 4/2/2012 7:11 PM, Adrien W. de Croy wrote:
>> So providing explicit support would make life a fair bit easier.  I'm
>> pretty sure everyone who wrote MITM was holding their nose at the time.
> ++yes, and we could probably also provide a mechanism for signing content
> e2e so the end user can still verify with the normal pki whether or not the
> integrity assertion of the resources match the host in the uris.
> I'm as firm on TLS-everywhere as anyone, but I recognize in some
> situations the user will need to consent to a non e2e version. Informed
> consent with reasonable granularity (Will's mention that CONNECT or
> block-me is still appropriate for a subset of things) is critical here, as
> is the elimination of passive attacks. That is still a massive win for
> privacy. The framework for consent needs work, and things like wpad
> probably need a new looking over. Undeniably hard stuff.
> We've got time for all of that if we're pointed in roughly the same
> direction.

Maybe I'm misreading the direction of the conversation, but I'm actually
pretty excited here since people seem to be agreeing that we should try to
provide a better path (explicit trusted HTTPS proxies) than lame SSL MITM
proxies. These problems with deciding between end to end or GET
https://and integrity checks on trusted HTTPS proxies served content
are difficult
to solve, but I think it's tractable and very worthy of more brainstorming
/ discussion.

> -P
Received on Monday, 2 April 2012 23:28:05 UTC

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