Censorship Resistance

In the previous chapter we added DNSSEC and DANE into the mix. It gave
us global uniqueness while retaining human memorable certificate
names.

The name is in two parts. The nickname @@ site name.

We have the registry to validate whether a Certificate Authority keeps
its promise to certify each nickname only once. It is to make sure
that there is always one public key for each name, that of the person
who signed up for it.

With DNSSEC we can be sure that at any point in time there is only one
site with its FPCA that can be found by resolving the site name. But
we cannot be sure that it is always the same result for the name. It
could be that the site name points to a different site than the site
owner wants. It could be that the DNS-registry was hacked, or it was
an untrustworthy registry that takes matters in their own hands. Or it
could be an untrustworthy government that ‘decides’ that a certain
site should ‘disappear’.

While there is no way to prevent these ‘attacks’ against the
DNSSEC-records, we can easily detect them. And with that we can
protect the visitors of the site from accidentally logging in at the
wrong site and losing their security and anonymity. We put that
detection into the user agent software.

Here’s how it works:

So far we’ve only spoken about client certificates. These are signed
by the First Party Certificate Authority. It’s the CA of the
site-operator. Why not let him sign the server certificates
too. After all, if you already have the equipment to sign
your clients’ certificates, it would be a waste not to sign your
server certificate too. That certificate gets published with DANE.

And there lies the catch. The server and client certificates are
signed by the same CA. It is something we check before we log in with
any of our certificates we hold. When a site requires us to log in
before we can use it, our user agent will only consider the client
certificates that are signed by the same CA.

If there are no client certificates that bear the signature of the CA
that signed the server certificate, it means it’s a new site.

In other words, the site has a identity that is independent of it’s
name. The identity of the site is the FPCA of the site. Each client
certificate already contains the identity of the site.

The name is vulnerable to maniputations but the identity is safe. If
the site operator followed the procedures correctly he doesn’t have
the FPCA’s private key online. It sits safely in a vault on a smart
card.

The name can be changed by the powers that be, but no one can
impersonate the sites’ identity. The person redirecting the site name
must use his own FPCA to sign the new server certificates. This FPCA
has a different identity, so it won’t match the identity of the
existing customers’ certificates. The only thing that happens is that
existing customers cannot log in anymore. Their user agent detects
that the name and identity won’t match anymore and raises an alarm.
(footnote: under no circumstances should the user agent allow the user
to select certificates based upon the name only. That would defeat
this protection and make the user vulnerable to Man in the
Middle-attacks.)

New customers, who don’t have any certificate with the ‘correct’
identities are not left out in the cold. As soon as they have signed
up for a certificate they can register it at the Global Registry. The
registry can check to see if this new certificate is signed by same as
all the other certificates with that site name. If there is a
discrepancy, it’s a sure sign there is something wrong. It warrants an
alarm on it own. And our new user is warned.

If it happens a lot that sites lose their DNSSEC name, it warrants
another lookup method. Just as people can sign a message stating where
they want their messages delivered, the site owner can sign a message
with a new address. He takes the FPCA smart card from the vault, signs
a message that specifies the new address (be is a new domain name, an
IP-address or even an onion-address) with the FPCA and posts it on the
net where everyone can read it. It could even be handled by the
registry. Now every user(agent) that comes across that message can
connect, validate the server certificates and log in with his matching
client certificate. The site has changed it’s name and network address
but it wasn’t take out forever. Just slightly inaccessable.

That’s what we call: Censorship Resistance.