CAcert System Admins discussion list

[samj AT samj.net]

CN schotzophrenia absolutely needs to be nailed down. I believe the
world believes that when CAcert sets CN it is via the WoT, and we
should work to make reality match expectation.

For domain ownership forget about registry databases and whois-we
can't access them universally and corrupting whois data can result in
domain loss.

On the other hand, random, repeated, automated checks are kosher, but
not for humans as this leads to phishing. So, checking a cname record
exists or a HTML file or a metatag or just some cookie could raise the
bar somewhat, essentially for free.

Sam

On 8/17/08, IanG 
<iang AT cacert.org>
 wrote:
> 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
> _______________________________________________
> CAcert-sysadm mailing list
> CAcert-sysadm AT lists.cacert.org
> https://lists.cacert.org/cgi-bin/mailman/listinfo/cacert-sysadm
>