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

Re: Trusted proxy UI strawman

From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Sun, 15 Jun 2014 22:09:40 +0100
Message-ID: <539E0B94.4090600@cs.tcd.ie>
To: Martin Nilsson <nilsson@opera.com>, ietf-http-wg@w3.org

On 15/06/14 21:34, Martin Nilsson wrote:
> On Sun, 15 Jun 2014 21:48:55 +0200, Stephen Farrell
> <stephen.farrell@cs.tcd.ie> wrote:
>> I'm not sure that I'm exactly clear on what's proposed but in any case
>> the above is not at all attractive. I thought we had already had the
>> discussion here that ended up concluding that MITMing TLS is not the
>> way to try tackle an HTTP problem. The MITMing-TLS approach has been
>> proposed and rejected many times.
> The problem is that it hasn't been rejected in practice. 

Please see the archives for earlier discussion. I'll try to
only make points I don't recall having been made on this

> There are a lot
> of root certificates installed on the client side to facilitate
> MITM-TLS-proxies. This is not good.

I would characterise the problem differently. There is no
HTTP proxy solution that has been adopted for the few (or
maybe even only one) real use-cases for policy checking of
TLS secured sessions.

> The TLS aims to make communication with the highest degree of
> confidenitality and integrity possible. That is good. Unfortunately it
> is entirely binary, 

That is not correct. There are many independent parameters
affecting TLS and literally hundreds (unfortunately) of
ciphersuites with different properties, and in fact some of
which do offer NULL confidentiality.

> so if an intermediary wants to do anything with the
> traffic, block specific URLs or add additional headers, it has to drop
> the security to zero. 

See above. And "drop security to zero" is a meaningless

Frankly, I think analysis such as yours above is very
obviously not a sound basis on which to propose significant


> That is not good.
> /Martin Nilsson
Received on Sunday, 15 June 2014 21:10:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC