Re: Trusted proxy UI strawman

Hi Stephen,

Since pinning is not enforced if the trust anchor is a user inserted CA, browsers support MITM today. Whether this is TLS being borked or HTTP being borked  I don't know. 

But by burying your head in the sand you are implicitly advocating:

MITM without user notification
Non-enforcement of pinned certs
Forgery of certificates and therefore transitive trust

As opposed to what I'm proposing (Mcgrew draft plus something like http://caffeinatetheweb.com/presentations/trusted_proxy.html) which in broad terms is:
User notification of the presence of trusted proxies
The ability for users to opt out on a per site basis or globally
Pinned cert enforcement
Ability for user and browser to examine the original certificate

Yes we have had this discussion previously. But I don't think we reached consensus. Also, the fact that my company is building a browser and looking for protocol design and security inputs on trusted proxy from the community is a new development. It'd be great to get your thoughts on how best to do it from a security perspective.

Thanks,

Peter

On Jun 16, 2014, at 6:34 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

> 
> Hiya,
> 
> On 16/06/14 04:01, bizzbyster@gmail.com wrote:
>> Hi Stephen,
>> 
>> Our users want this so we are building it -- and we prefer to provide
>> them with a mechanism to opt in and out on a per site basis as well
>> as solve the problem of transitive trust introduced by standard MITM
>> proxies. While changes to the TLS layer are not required, it is the
>> most straightforward way to provide optimization for HTTPS web sites
>> for a service provider that has already deployed web acceleration via
>> proxies for HTTP-schemed web sites. Ideally the protocol changes we
>> make to our proxy and our web browser, including users on commercial
>> airlines like JetBlue and United, will be standardized so that our
>> users will get optimization when using other browsers and also when
>> they are using our browser when communicating with other proxies.
> 
> I think the word "user" in the above is conflating people (with a
> browser), content authors and n/w operators, at least. I (as a
> user visiting web sites) do not "want this," nor do I as a content
> author, nor do I as a (very very tiny:-) web site admin. And I
> definitely do not "want this" for my calendar nor IMAP etc.
> 
> So I don't agree that borking TLS is the most straightforward way
> to do something that I want, for at least 3 or 4 definitions of
> me as a user. And I'm pretty sure that I'm not at all alone in that.
> (But wasn't a lot of the above said already on this list?)
> 
>> "If HTTP needs a proxy solution,please aim to develop an HTTP
>> solution and do not affect the many other protocols and applications
>> within and beyond the IETF that depend on TLS and that do not need an
>> MITM."
>> 
>> What did you have in mind? I'm really interested in alternatives that
>> do not involve modifying the TLS layer.
> 
> Mostly I have in mind not borking TLS;-)
> 
> I'm sorry to seem so negative here, but when there are such
> conflicting requirements, I guess that's gonna be the case.
> In my defence, I think I can fairly claim that "don't bork
> TLS" is actually a positive statement overall.
> 
> Cheers,
> S.
> 
> 
>> 
>> Thanks,
>> 
>> Peter
>> 
>> 
>> On Jun 15, 2014, at 3:48 PM, Stephen Farrell
>> <stephen.farrell@cs.tcd.ie> wrote:
>> 
>>> 
>>> 
>>> On 15/06/14 20:34, bizzbyster@gmail.com wrote:
>>>> The whole idea of this proposal is to make it no different than 
>>>> today's MITM ...
>>> 
>>> 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. If HTTP needs a
>>> proxy solution, please aim to develop an HTTP solution and do not
>>> affect the many other protocols and applications within and beyond
>>> the IETF that depend on TLS and that do not need an MITM. And that
>>> might not have a user or browser or equivalent.
>>> 
>>> I mean we could repeat all that debate, but it seems better not to
>>> do that to me at least.
>>> 
>>> S.
>> 
>>