[SSL Observatory] Tangent - coercibility of different authority structures

Phillip Hallam-Baker hallam at gmail.com
Mon Sep 26 07:04:28 PDT 2011


On Mon, Sep 26, 2011 at 2:22 AM, Matt McCutchen <matt at mattmccutchen.net>wrote:

>
> > Russia, China and Iran would be fools not to lobby for the DNSSEC
> > scheme because once a single point of control is established it will
> > be a trivial matter for them to usurp it within their own territories.
>
> Huh?  If you have the real IANA public key, any attempted usurpation
> outside the CCTLDs controlled by the respective countries is obvious.
>

There is an infinite number of solutions you can get to if you can be
assured of getting to ground truth.

But what Iran has already been doing is to distribute versions of Windows,
Firefox (and yes, Tor) that have been Trojaned. You can be certain that
Russia and China will prohibit distribution of Windows etc with the ICANN
key.



> Whereas with the disjunction of 100+ CAs, if Russia has one CA, it can
> defraud users with respect to the entire namespace.  If you were
> thinking of a different scenario, could you spell out the outcomes under
> the two systems to help me understand?
>

Your claim would be so much more credible if you would stick to the facts.
There are 20-30 CAs, not 100+. If you want to claim that there are more you
need to prove that there are more.

Russia will block distribution of any DNSSEC software that does not use
GOST. That is what GOST is for.


The simplest way of using DNSSEC is to use DNSSEC as one of the options for
signing security policy and then use the security policy to pin either a CA
issued EE cert or a CA issued intermediary cert to the domain as
appropriate.

But DNSSEC should only be one option for signing security policy. Mozilla,
Microsoft etc should have the option to sign policy for their browsers as
well.

We do not need to irrevocably hand over control to ICANN in order to solve
this problem. And when the basis for that hand over of control is a paper
that makes a claim that the authors admit they can't really justify, well,
it simply ain't going to happen.


I appreciate your intentions of providing distributed control through
> multiple CAs.  But as long as the system is structured as a disjunction,
> all it provides is increased attack surface, some of which may lie right
> in the countries in question.  Do you propose to change that?
>

>From the start I proposed to use the combination of the DNSSEC and CA chains
so that EE certs would have to be compliant with both.

That was the basis for the original version of CAA which had the path
statement and client enforcement in it. Now the people who forced the
removal of those features from the PKIX version of CAA are the same people
who are claiming that the CA model is irreparably broken.

So people are saying that the model is broken but they are trying to make
sure I can't fix it... hmm.



> And if the alternative mechanism is weaker, the government will just
> cause the main mechanism to default all the time, so you haven't really
> explained how to reduce the problem.  Phill, if you're interested in
> working on this seriously, please poke me and maybe I'll actually set up
> a mailing list like I was thinking of before...
>

The issue is separation of duties.

Merely replacing the CA PKI with the ICANN PKI is to return to the original
CA model we had back in 1995 when there was one CA and it ran its SOC using
a scheme based on the crypto handling procedures of the NSA. It is even
called VeriSign!

Unfortunately looks are deceiving. VeriSign is only running some of the
registries. The country code registries will be run by the very governments
that are the problem. Plus there is the unfortunate fact that DNS registrars
are a chaotic mess, many of whom don't even know how to authenticate their
own customers reliably.


So a scheme that eliminates CAs and relies only on the DNS system for
authentication would not be an improvement.

But a scheme that forces a government to compromise both the CA PKI and the
DNS can be made a lot harder to break.


-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/observatory/attachments/20110926/40cc8e17/attachment.html>


More information about the Observatory mailing list