Re: report on EV and SSL MITM proxying

On 8 Mar 2011, at 18:58, peter williams wrote:

> After 15 years of trying and 10 major vendors, isn’t it a bit surprising that none of them have reduced it to a trivial easy UI? It’s so easy!

Indeed, it is surprising, and it is easy to improve :-)

>  Hardly a logical argument; peter. Far too empirical!

So I suppose if Galileo found that the earth turns around the Sun, you would have argued that this was impossible because for the previous million years nobody had thought of it.

Science moves in weird ways. You can't argue from the fact that something has not been done, that it can't. And you can't argue that because your opponents are rich that they must be right. After all Galileo had the Pope against him. 

Think rather what is NEW in what we are doing, and think why there was not much momentum for client side certificates.  I explained that already a few times. Client side certs that can only be used on one web site are NOT very useful. They only become useful when useable globally. And they can only do that with URIs. So the problem with client side certs was:
  - using distinguished names
  - lack of linked data
  
So we solve these problems the rest  is easy. There will then be an incentive to improve the User Interface.

>  
> Try to go through Ryan’s argument; he actually answered you logically. In defending EV, he distinguished it from other server certs that *some* browsers will not clearly characterize as having been MITM’ed.

It may be useful to have browsers show that they are using proxy certificates. If this is your UI improvement proposal it sounds ok, but it's not a big deal. You can see why not a lot of time was invested in this.

> Having thus acknowledged the world of SSL MITMing as a fundamental threat, he then suggested: perhaps look for user id protocols OTHER than TLS client authn.

My argument is that it is not a fundamental threat. You make it sound like TLS does not work. But in fact it works very well. If you are in control of your OS and machine you will not be able to work through these proxies - ie: you will be blocked from revealing information to a third party which is what you want.

Whatever system you come up with will have this problem: if you need to use someone else's network and they want to see what you are doing and communicating they will be able to argue that they should not pass on the information unless you give them the keys. Be that using TLS, XML encryption or anything else.


> He outlines how the world involving any cascade of SSL MITMing proxies (needed for social/corporate “interests”) interferes with end-end client authn, precluding its use beyond interaction with the first proxy in the sequence. He didn’t say it, but this is not a real constrain if that proxy is now a websso IDP, than translates the layer4 assertion into a layer 7 signed token that bypasses transport bridging.

Social Corporate interests are not necessarily evil. They are larger agents and if they need to see what is going on their network, they will only be able to do so if you accept to give them access to your machine. And this will be so whatever technology you use.

So in fact the legal uses of TLS work correctly, the illegal uses of TLS work correctly. There is a gray zone with corrupt CAs, but that will be dealt with ietf DANE and DNS-SEC. 

>  
> Not really my words, and really not my argument. I just elicited the words and arugment from folks that others here *should* find reputable.
> 
> 
>  
> From: Henry Story [mailto:henry.story@bblfish.net] 
> Sent: Tuesday, March 08, 2011 12:03 AM
> To: peter williams
> Cc: public-xg-webid@w3.org
> Subject: Re: report on EV and SSL MITM proxying
>  
> Some folks suggested that life would be all rosy, in webland, if the browser displayed which client cert had been presented to a given website (per tab, presumably). How come those over-complicating security designer types, just don’t do simple and obvious things, when its ALL so EASY if one just thinks minimally and logically!
>  
> I have not seen an argument in what you have put forward that shows that this is not an easy thing to do. The only arguments from browser vendors I have heard, is that client certs are not widely used, and so it has not been a priority for them.
>  
>  

Social Web Architect
http://bblfish.net/