CAcert System Admins discussion list

[IanG <iang AT cacert.org>]

OK, I now see what is going on with the grelisting!  Reality 
was reversed from my assumptions, so conclusions were 
hopeless....  It's like this:

1.  email probes are sent out by the critical services in 
Vienna.
2.  a probe on a CAcert.org address comes in to CAcert email 
servers in BIT/Ede.NL.
3.  incoming mail is greylisted by Tunix, so new addresses 
are apparently blocked for some 5 minutes.  (was that new 
address iang AT cacert.org or the probe-sending address?)
4.  Tunix are operating the greylisting under agreement with 
Oophaga.

Apologies for the confusion, thanks for all the help!



The rest of the discussion has morphed into a commentary on 
how weak email probing is.

Which is one of the two big issues facing the CPS right now. 
 (The other is the schitzophrenic behaviour of CN=myname.) 
 As the email/domain checking is too weak to pass audit, 
because of the audit criteria demanding more, it's worth 
battling on!





Philipp Guehring wrote:
> > We may have to face some tough choices here:
> >
> > either it is reasonable and strong enough to rely on ... in which case
> > we are concerned about any weaknesses such as external people
> > fiddling, because that weakens it....
> The problem I see is that the core-internet infrastructure does not
> offer any secure mechanisms. There is no SSL-enabled whois available
> from whois providers, and there is no secure DNS provided at the moment,
> and there are no alternative access methods to those.


So what we are saying is that there is no cryptographic 
security mechanism that will satisfy the generations of 
cryptographers who subscribe to the notion of perfect security.

Sure.  But that metric is not useful.  If it were applied to 
our Members, we'd have to kill them all because they are not 
cryptographically self-securing as far as their Names go. 
As we aren't likely to apply that metric to individuals, it 
seems overly painful to expect perfection from everything else.


> So unless we run
> our own worldwide internet backbones, run our own DNS registry, or get
> the existing ISPs and registries to offer secure mechanisms, we can't do
> very much more than what we are doing already.


Let's not be hasty.  What is done now?  One static check on 
adding the domain, once.  Most of the attacks involve 
temporary glitches in the DNS system.  So we can address 
these by running repeated checks.

More openly, we have these options available to us:

   when a certificate is requested.
   random times.
   from different places.
   to different email addresses.
   when the user requests it.
   when the old check is older than X years.
   when something like the registry details change.

Another attack is stolen domain registrations.  This is a 
somewhat narrower problem because (a) these attacks are 
mostly limited to accessing https or login websites, and (b) 
there is a better developed legal and dispute resolution 
process backing it up.  By that I mean that if I steal a 
domain by changing the registry information, I have to deal 
with a response from the registry and/or owner that is now 
somewhat familiar.  Stealing DNS service is not so well 
understood as a dispute resolution.

This would suggest that the registry information is somewhat 
better protected than DNS information.  Also, it is somewhat 
of an understood concept to add some string to the registry 
information.

Another option is to add a string to the website.  For 
example, we could simply ask people using the CAcert 
certificates to secure their websites to add a CAcert logo. 
 If they can do that, that shows some control.  If it stays 
there, that shows long term control and/or interest.  It 
also shows a long term "permission".

So that is three things that can be done.  All three are far 
from perfect.  Which are chosen, or which others are 
available, is something to discuss.


> > it is not really strong, can't be fixed easily, and shouldn't be
> > relied upon.  In which case, using it to show that the Member has
> > control over the domain/email is weak. And we need to think up
> > something stronger.
> There currently is no stronger mechanism available.
>
> Even if we phoned up the registrar to ask whether a particular domain is
> owned by a specific user, the telephone provider might do an MITM attack
> on our telephone-call. (Or anyone having an IMSI-Catcher ...)


Sorry, security is about the analysis of risks, benefits and 
costs.  It isn't about eliminating all threats, it is about 
addressing the threats with reasonable and cost-effective 
defences.

This "perfect security" sort of thinking was shown to be 
flawed in the 90s.  It caused the "SSL equals security" myth 
which lead to phishing and a range of other failures.


...
> > For the audit, it is a DRC problem:  the criteria are much tougher and
> > CAcert has to add more email checks or something similar.
> Which of the threats in that area are you specifically afraid of, and
> which don't you care about?


The DRC is rather prescriptive on what it wants done.  It 
does not provide a risk analysis.  This leads to several 
possibilities for CAcert:

  1. DRC says what should be done.  Just do it.
     https://financialcryptography.com/drc/browser.php
     Click on pingtest then Go.

  2. Reverse-engineer what was in the author's mind, and 
try and address his threats and risks with your defences 
rather than his prescribed defences.

  3. Do your own threat and risks analysis and propose that 
this result is over-all better.

I guess all these opportunities have their merits, pick one? 
 Either way, it will still have to be measured against the 
criteria in some sense or other.

iang