CAcert System Admins discussion list

[Philipp Guehring <philipp AT cacert.org>]

Hi Ian,

> I'm concerned about external parties doing stuff with email.  It is a
> governance issue rather than a technical issue.
Then you shouldn't use email at all. Email is by definition a
Store-Convert-Forward system, where every MTA is allowed to change things.
> I don't care what the stuff is so much, as the fact that they are
> doing it.  If they are doing it, it is easy for them to do a whole lot
> more.  (This is the game that people play to do a breach.)
In that case, SMTP based email is the wrong tool.

> The thing is, the online system is imposing or being imposed some sort
> of delay on sending out the email to prove control.
Which is done according to the specification of SMTP.

>>>>  
>>> No, since Tunix does not operate a firewall in front of our critical
>>> systems at the moment, it only operates a firewall in front of our
>>> non-critical systems, which are doing email and other things.
>
>
> The above two comments indicate that this is nothing to do with Tunix,
> so basically the situation is that you have turned on the grey
> listing, and it is an internal CAcert thing?
No.

The email ping works the following way:
The website (critical system) in vienna generates the email and sends it
directly to the responsible mailserver of the target domain. In case of
@cacert.org email, this is the Tunix mailserver in NL, which has
implemented greylisting there. In case of the domain futureware.at, this
would be the email.futureware.at mailserver in AT.
So if you want to do an email ping with a @cacert.org email address, you
have to cope with the greylisting of Tunix, if you do the email ping
with any other mailserver, then the email is delivered directly to that
other mailserver (which might or might not have implemented
graylisting). So for a @futureware.at email address, Tunix can't modify,
delay or anyhow else tamper the email ping.


>
> OK, that is fine.  I have no problem with CAcert deciding to run
> greylisting or polkadotlisting or whatever.  That's internal, and
> presumably you can make the best choices there.
>
> It is when it is done by an external party that the eyebrows go up... 
> External parties doing stuff that impacts assurance or issuance
> decisions are an issue.
It only impacts @cacert.org addresses, nothing else. So I would say that
it's an internal problem only.


> Ah.  So, the problem with this explanation is that it leads us to
> consider that email probing is not really that strong.
Depends on whether you trust the core-internet infrastructure or not.

> 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 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.

> 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 ...)

>
> Did I miss something?
Hmm, one thing we could do is to send our assurers to the office of the
DNS-registrars to ask for and verify the ownership of the domain.


> OK, Sam suggests encryption and signing.  I'm not sure, isnt that
> chicken and egg?  After all, it implies that we have the user's cert
> and they have our cert ... which might make it brittle.
Yes, signing would help, if the DNS registrars would sign their whois
records and their DNS zones.
But I currently do not see a viable way of getting DNS registrars to
start signing their stuff, since it doesn't provide them with any value
to do that.
But this all doesn't help against a rogue mail-admin who impersonates
one of the users on his servers.

> OK.  Let's ignore Vienna for the moment.  When rebuilt in NL, how much
> weight do we feel like putting on the email probe test of control?
I am currently tending not to put the Tunix firewall in front of the
critical systems in NL.

> Right.  So for the technical side, this becomes a question for the
> near future, not a question for today.  But as it looks fairly complex
> (none of us recalled that the systems can't be blocked by Tunix right
> now :) then as good to think about it now.
>
> For the CPS it is a question for now;  we are trying to write the
> Relying Party Statement and need to know whether the emails and
> domains in the certificates can be relied upon (have been verified for
> control).
Verisign and GoDaddy went the way of joining a Registrar with a
certificate authority, to solve the problem of getting correct registry
data to the certificate authority. (Well, they didn't solve it, since
they also issue certificates to users of other registrars, but at least
it helped)

CAcert also thought about starting a domain-business, (due to it's
relationship to E164.org) some time ago, but it was then decided that it
wouldn't solve enough of the problems, since we can't start a registry
for all top-level and second-level domains.

> 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?
* Rogue email-server admins impersonating their users
* Backbone providers doing MITM
* Upstream-providers from CAcert doing MITM
* Upstream-providers of the target DNS doing MITM
* DNS Server providers injecting wrong data in their DNS servers
* Attackers using exploits to inject wrong data into DNS
* Attackers using exploits into browsers to take over others's domains
* Attackers using exploits against mailservers to redirect or sniff the
EMail pings
* Something else?

Best regards,
Philipp Gühring