Re: [therightkey] Basically, it's about keeping the CAs honest

["Kyle Hamilton" <[e-mail]>]

On Mon, Feb 13, 2012 at 8:36 AM, Martin Rex <[e-mail]> wrote:
> The fact that there are products (client-side HTTPS proxies that
> perform MITM and inspect content) actively sold and used,
> which are vitally dependent on being able to exploit weaknesses
> of the existing TLS X.509 PKI security&trust model, is a sure proof
> that something is wrong with the existing security model.

I completely agree.  The existing security model does not take into account the fact that owners of networks get to impose their own security policies, and aims to do everything it can to prevent useful deployment of interoperable low-security routine key-continuity verification that isn't "pay to play".

> I do not think there is value in maintaining backward compatible
> weaknesses, and personally, I do not mind the slightest about breaking
> those protocol subverting middle boxes, be it by the use of TLS channel
> bindings, or the checking of DANE TLSA records.

There are environments in which the data sent off of the network MUST NOT be unknown to the network owner/operator.  This is not by any protocol standards body action, but rather by law or regulation.  It's just like the original order from DARPA Command, that TCP/IP would be used on ARPAnet -- once it comes down, it's too late to argue.  I think law rather trumps our desire to deprive everyone of the capacity to perform MITM.

We can continue to outlaw it, in which case it will continue to exist outside of our sight.  We can continue to do the things we've tried to do before, to break what currently exists and to try to prevent technological subversion in an arms race.  That will only ensure that other standards bodies will step up to fill the void of workable standards for authentication, and ensure that companies will still do anything they can to make a buck and find ways to subvert our in-loco-parentis "you can't do that, it's for your own good" security model.  It's time for us to get over ourselves.

There might be a useful compromise: the built-in/vendor-supplied roots show a blue or a green address bar, and non-vendor-supplied roots show a yellow address bar.  Eventually, this might lead to the partitioning of "vendor-supplied state identity service provider" from "these CAs are known to issue to businesses which must ensure complete knowledge of all incoming and outgoing data, but nevertheless provide a useful service to the browser user", with the latter provided by the vendor but also being shown in yellow within the application.

Or, you know, any certificate that's issued to * or *.tld could just as easily be displayed in yellow.  Nobody considers that it's ultimately the application developers who decide whether to allow and how to present anything we come up with.

I think the existing mandate that everything be authenticated and tunneled end-to-end only hurts the IETF.  We need to develop systems within models that actually work.  I am here as the voice of the user and of the network administrator, the one who needs to be able to trust his hardware and software to do precisely what he expects them to, the one who needs to actually use the services we specify.

-Kyle H