[cryptography] Why anon-DH is less damaging than current browser PKI (a rant in five paragraphs)

Jeffrey Walton noloader at gmail.com
Mon Jan 7 04:52:02 EST 2013


On Mon, Jan 7, 2013 at 2:31 AM, ianG <iang at iang.org> wrote:
> There are two long-term trends that might inform this argument.
>
> 1.  Vendors have typically refused to improve the model of browser security
> if it has involved changes to the model.  There is a long history of people
> providing suggestions, papers and code, and the vendors have ignored them.
> It is one of the more compelling evidences that vendors do not have users'
> interest in mind, taking their guidance from the supply side.
The basic question for the CA: how does it affect their revenue. If it
does not improve revenue, there is no reason to entertain the change.

If the proposed improvement addressed a technical or security related
gap, then its cheaper and easier to have the lawyers add three pages
to their hundred page CSP.

OT: has anyone analyzed a selection or subset of CPS from top CAs?

OT: how can a CA change their ToS and CPS like Trustwave after the
fact? That was a Material Adverse Change (MAC), and there was no
meeting of the minds.

OT: Has Mozilla (et al) addressed the gap in their policy? Otherwise,
the game will be: get added as a Root CA with benign a CPS for users;
and then once accepted, absolve all responsibility and make the ToS
and CPS toxic for users.

> 1.a the current rebel from the trend is google.  The reason for this can be
> seen in its business makeup.  google unlike the rest is both a vendor *and a
> user*.  As it has come under attack for its second role, it has sought to
> defend.  CAs have not been of any use.  As an engineering-heavy company, it
> has seen engineering improvements that could be made.  For this reason,
> google can be seen to be experimenting with changes, and continuing to do
+1 to Google.

> We should welcome these early experiments, wherever they come from. This is
> regardless of whether they are good, bad, up or down.  The only way to fix
> the mess is to change internal architectural assumptions of the browsing PKI
> (e.g., including as people have pointed out the brittleness of one-for-all
> and all-for-one aspect, perhaps we should refer to at as the 3 Musketeers
> weakness).  The point here being that you might get to consider the really
> serious problems of the model once you have gained some confidence fiddling
> around at the edges.
Well, I don't think PKI and Public CA Hierarchies are going away. I
don't disagree with Dr. Gutmann
(www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf). It's just PKI
and Public CA Hierarchies are too entrenched. So you have to explore
hardening techniques that address existing gaps (such as pinning and
pinsets).

 > ... and the
> recent addition of root revocation capabilities in the last 3 years.  In the
> nick of time it might seem, but every action has consequences.
Speculatively, the change occurred because of folks like the SSL
Observatory and CT.

I's typical 'catch me if you can' in the United States of Corporate
America. CAs can now be caught (as demonstrated by TÜRKTRUST) so they
need us to perceive concern. I doubt the process will ever be
exercised or invoked.

> Which is to say, now that vendors have taken on the role, and become the
> über-CAs, they are more likely to PKI-us-harder than lesser.  E.g., google's
> current trend with pinning, CT, and dropping self-signed certs are obviously
> that, as they do more with PKI not less.  It's going to take a while before
> they get frustrated at this.
I believe pinning is good. The root of the problem is 'conferring
trust', and pinning removes the conference.

Note: its not just CAs - it's DNS too. The pinset removes the hearsay
answers given by CAs and DNS which we were previously making security
decisions on. Put another way - we don't care what answer we get back
from CAs or DNS.

Revocation is still a problem, though. Dr. Gutmann was so right with
respect to so many things in his deck.

>...

Jeff



More information about the cryptography mailing list