Re: Trusted proxy UI strawman

Hi Peter,

On 16/06/14 15:05, bizzbyster@gmail.com wrote:
> 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

I suspect my head is above at least one parapet:-)

The metaphor is also fairly unfair. I'm disagreeing with
your proposed solution, not ignoring it.

Were I to accuse the proponents of various ways of
borking TLS of burying their heads in the sand because
they have clearly not done the analysis of all the
impacts of such, that would be equally unfair. So I've
not:-)

But here's [1] the list of the 195 RFCs that cite RFC
5246 in case that helps. And here's [2] the list of
1785 publications that Google scholar lists that cite
RFC 5246. When someone has produced an analysis of the
impact of their favourite way to make the major change
of adding a 3rd party to TLS on those then I will be
interested in reading that. The corresponding numbers
for RFC 2246 are 167 RFCs and 3155 citations btw, and
those also need to be considered.

Yes, that is quite an ask. But a major change to a
very widely used protocol like TLS should be.

> you are implicitly advocating:
> 
> MITM without user notification Non-enforcement of pinned certs 
> Forgery of certificates and therefore transitive trust

I am definitively not "advocating" for any such thing.

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

I think "trusted proxy" is a misnomer and misleading and
in general "trusted foo" is probably better not part of
any technical discussion on this topic since the question
of who is trusting whom for what is complex here and
ignoring that complexity IMO does a disservice to the
various interested parties.

And from a security perspective: the best way to not
bork TLS is just that.

Cheers,
S.

[1] http://www.arkko.com/tools/allstats/citations-rfc5246.html
[2]
http://scholar.google.com/scholar?q=http%3A%2F%2Fwww.hjp.at%2Fdoc%2Frfc%2Frfc5246.html&btnG=&hl=en&as_sdt=0%2C5

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

Received on Monday, 16 June 2014 14:57:41 UTC