CAcert System Admins discussion list

[samj AT samj.net]

I would suggest that there are some weaknesses that can be fixed, for
example by sampling the DNS from multiple locations, and that this is
otherwise strong enough for one time email verifications. That is,
enough to say that this person had read access to that email address
at that partiular instant. Using mail replies could give us a better
audit trail and would raise the bar if we were sensitive about SPF,
dkim failures etc.

Also if the token is to be embedded into the link then there should be
another cancel link which works even after acceptance, or at least
authentivation required so as automated link checkers don't pass the
check.

The separate question of domain verification is less clear. Auth codes
would be interesting, only not sure they can be verified outside the
transfer process and they are not universal, as CNAME, HTML and META
checking are.

Sam

On 8/11/08, IanG 
<iang AT cacert.org>
 wrote:
> Teus Hagen wrote:
>> Gentlemen,
>>
>> maybe I misunderstood Ian his email.
>
> I'm concerned about external parties doing stuff with email.
>   It is a governance issue rather than a technical issue.
>
> 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.)
>
>> Tunix is using grey listing on request of CAcert (they asked should we
>> turn it of and the answer was no).
>
>
> Ah, ok, good!  So, there is an agreement to do grey listing
> in place (and it will effect critical systems when put into NL).
>
> That is fine, as long as there is an agreement, and it
> states that is what they are doing, and doing other things
> like intercepting, copying, rejecting, changing, etc is not
> to be done.
>
>> Critical systems do an evaluation email trial. That is the other way
>> around (eg no grey listing is then active at the CAcert side). This is
>> outbound traffic not inbound...
>
> The thing is, the online system is imposing or being imposed
> some sort of delay on sending out the email to prove control.
> ...
>
>>>> OK.  Do we have any documentation on this?  Is this an
>>>> agreement between Oophaga and Tunix?  Does CAcert feel that
>>>> this is a "good thing?"
>>>>
>>> Greylisting is currently industry standard practice. I personally dislike
>>> it
>>>
>>>
>>>
>>>> That's to turn the question around.  Let me rephrase it so
>>>> it cannot be turned around, hopefully:
>>>>
>>>
>>>> If Tunix can fiddle with the mail, can Tunix add any domain
>>>> or email, and get a cert for it?
>>>>
>>> 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?
>
> 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.
>
>
>>>> Who else could do this "fiddling"?
>>>>
>>> Lots of people could do that. Everyone who is running a larger Internet
>>> Exchange could (VIX, DECIX, ...) probably could. Everyone running core
>>> DNS servers potentially could, ...
>
>
> Ah.  So, the problem with this explanation is that it leads
> us to consider that email probing is not really that strong.
>
> 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....
>
> OR
>
> 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.
>
> Did I miss something?
>
>
>>>> Obviously, the system
>>>> administrators on the critical systems (i.e., Philipp,
>>>> today) can do this.  That's why that is declared "critical"
>>>> because they can do things like that.
>>>>
>>> Yes.
>>>
>>>
>>>> The question is, who else *outside* the critical systems
>>>> circle can fiddle with email.  I'm guessing the answer is you :)
>>>>
>>> Everyone with access to the backbones, ...
>
>
> 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.
>
>
>>>> OK.  Threat models ... I do not see email fiddling mentioned
>>>> here:
>>>>
>>>> http://svn.cacert.org/CAcert/SecurityManual/RiskAnalysis.pdf
>>>> http://wiki.cacert.org/wiki/ThreatList
>>>>
>>>> but maybe I am looking in the wrong place?
>>>>
>>> Both lists aren't complete yet.
>
>
> Well, sure.  Threat models are never complete.
>
> Can we agree that this is a threat, and it should be listed?
>   What section?
>
>
>>>>>> who is poking around and greylisting and
>>>>>> blacklisting and goldlisting and whatever... ,
>>>>>>
>>>>> most email admins to some extent.
>>>>>
>>>> OK.  So that is:  You + Philipp?
>>>>
>>> + Tunix (for cacert.org and lists.cacert.org)
>>> + BIT
>
>
> 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?
>
>
>>> If we placed our critical systems behind Tunix firewalls, then we would
>>> have to start asking those questions. (Or perhaps even before ...)
>
>
> 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).
>
> For the audit, it is a DRC problem:  the criteria are much
> tougher and CAcert has to add more email checks or something
> similar.
>
> All by way of saying, it's a hotter topic than might appear
> apparent from the "bug report" :)
>
> iang
> _______________________________________________
> CAcert-sysadm mailing list
> CAcert-sysadm AT lists.cacert.org
> https://lists.cacert.org/cgi-bin/mailman/listinfo/cacert-sysadm
>