CAcert System Admins discussion list

[IanG <iang AT cacert.org>]

Hey, Sam,

I'd reckon we are roughly 179 degrees polarised on this. 
However, before I rebut your post comprehensively, let me 
say this:

I don't really don't mind what it is you guys come up with, 
or the policy group, or the board.  .... you guys make a 
proposition.

Right now, domain and email checking doesn't fly.  Over to you!

Now, back to the rebuttal :)

Sam Johnston wrote:
> Ian,
>
> This is a non-starter. If you corrupt the WHOIS you can lose your domain:
>
> "/Please remember that under the terms of your registration agreement, 
> the provision of false Whois information can be grounds for cancellation 
> of your domain name registration./"


Sorry, Sam, that doesn't cover it, it doesn't even come 
close.  Pointwise:

1. the information isn't false.  Nor is it misleading, 
deceptive, bad faith (see ICANN rules), negligent, or any 
other "bad thing."

2. it isn't material to any question, especially a question 
likely before an appropriate authority (which in this case 
is an ICANN Arbitrator, and the likely question is whether 
you are stealing a domain or breaching a trademark).  What 
case are you going to file?

"MiLud, Defendent used a CAcert certificate against ICANN 
rules."

3. it says "grounds."  That is, "evidence that is taken into 
consideration" in an Arbitration.  Think of the above 
statement as like being read your Miranda rights.  Hearing 
your Miranda rights does not mean that you cannot talk.

4. the first purpose of that statement is to create an easy 
award in filer's favour, in the event of failure to serve 
papers to the correct agent.  English common law requires 
you to serve the papers.  If the service attempt discovers 
that the address is false, then this is bona fide evidence 
of "false information."  Adding a hint that this is a CAcert 
interested party makes it somewhat easier to get a handle on 
this person, as the Arbitrator can say, "well, did you try 
CAcert?"


> It doesn't work for email. It doesn't work for chat. It doesn't work for 
> OpenID.


If you are saying that it won't work for all the users of 
these products, then sure.  I agree.  But that's a bit like 
the current system:  it doesn't work for all reliance 
purposes, only some, and them not adequately.

If you are saying that these products do not use domains in 
certs, then I would disagree.  It should work in any 
circumstance where a Member can get at the domain registry. 
 If not, then not.

(It works perfectly for most all organisation purposes!!!)


> It just works for domains and it's slow (WHOIS updates can be 
> infrequent), unreliable (varies from TLD to TLD)

It may be slow but it is persistent, as against a domain 
ping which *may be* faster but only lasts for a few second.

In this case, once a delegation is in place, the owner need 
do nothing more, it remains in place for years.  No user 
activity required.  This is a *significant saving* for the 
user, as the user is likely going to have to be 
probe-checked every time it is used in the future, and some 
other times as well.


> and own't work for 2LDs 
> and below,


I explained that before.  It works perfectly for lower 
domains.  The owner delegates all of it.  That's it.  The 
fact that the lower domain *controllers* cannot change that 
delegation is ... tough.  TANSTAAFL, Sam!

(It's about ownership, not control....)


> nor where the user of a domain is not the owner (it happens).


It happens, but it still works:  the point is that it is a 
manual act by the user / owner / controller, being an 
assertation of delegation.


> If you can prove you have control over a resource (eg by responding to a 
> ping, creating a CNAME, sending a chat message, etc.) it should be good 
> enough for CAcert.


Showing control is good too.  However, if you think handling 
domains is too hard for users, then you can give up on DNS. 
  No users that I've ever come across deal with DNS.  Even 
experienced techies run like hell from that.


> Ownership of the resource itself is, so far as I can 
> tell, unnecessary for our security model.


LOL....  Onership of the resource is *entirely sufficient* 
to delegate the authority to use or control or issue certs, 
in any way possible or supported.  That is what ownership 
is: the right to say how it is used, who uses it, and where. 
 If the owner of the domain decides to delegate all 
certificate "rights" to a CA, then she can.

Ownership trumps control and security.  Security is there to 
serve members, and that always starts with what they own. 
The moment security models tell owners that they can't use 
their rights of ownership is the time to turn that security 
model off.

E.g., if a domain owner comes to CAcert and states that all 
certs should be revoked, and she has lost control over the 
certificate, what is the Arbitrator going to do?  Revoke. 
It's hers.

E.g., In a recent San Francisco case, the security model 
locked out the managers.  The guy who did that was arrested 
and hit with $5,000,000 bail.  He's toast.

Ownership trumps control!  Never forget that!

iang


> On Mon, Aug 18, 2008 at 6:05 PM, IanG <iang AT cacert.org 
> <mailto:iang AT cacert.org>> wrote:
>
>     Hi Philipp,
>
>
>     Philipp Guehring wrote:
>
>         Hi,
>
>             I was thinking about that last night.  First of all, want to
>             show control of the domain.  We want to show ownership /
>             legal / responsibility control, more than any technical
>             control, because ownership and legal responsibility trumps
>             the technical control.
>              
>
>         Yes, showing ownership and legal responsibility is better,
>         but it's usually more costly. And I guess there will
>         be lots of situations where it isn't possible.
>
>
>
>     Ah, I see a confusion here, perhaps I should have been clearer.  We
>     can't exactly "show" legal / responsibility control, we can simply
>     do due diligence, which is that diligence due to the situation.
>
>     In the terms that you imply about -- searching for an absolute --
>     that is up to the courts, or our Arbitration if it has jurisdiction.
>      For us alone, today, the essential thing is setting up a reasonable
>     set of tests that cover the territory.
>
>     So the whole sentence might better read:
>
>     There is an advantage in doing due diligence on ownership / legal /
>     responsibility control, over any due diligence on any technical
>     control.  That is because, if we show (in court) technical control,
>     this may still be falsely delegated, whereas if we show ownership
>     and legal responsibility, we eliminate that step.
>
>     Or something.
>
>
>         How do you proove legal responsibility for an email address?
>
>
>
>     So, the answer to that is to do the due diligence that will survive
>     in court.
>
>
>             Which means we should preferably be looking at the domain
>             registry.  DNS is a subsidiary service to the domain
>             registry, so it will always be second best, it will never
>             show legal/responsibility control, only technical control.
>              
>
>         Yes.
>
>             So, why can't a string be inserted by the member into the
>             domain registry fields?  Hypothetically, "CAcert-Auth".
>              
>
>         The problem is that the various domain registries are
>         running various different databases, and provide neither
>         direct nor digitally signed or somehow else secured access
>         to those databases, as far as I know.
>
>
>
>     How about this:
>
>         $ whois iang.org <http://iang.org> | grep CAcert-auth
>
>     Sure, it isn't "secured", but we have to get over this reality issue.
>
>     I don't know why this is so hard.  Over at another group I deal
>     with, we've set a standard that the technical contact for hosted
>     domains should be set to the single DNS technical contact for the
>     organisation, not the owner.  If they can do that, we can set a string.
>
>     After all, CAcert is a technical authority when it comes to
>     certificates :)  Why can't authority for certs be delegated, a
>     little bit?
>
>
>         Regarding whois access:
>         There are no comment fields in whois, so I guess
>         it will be hard to put "CAcert-auth" in it, without
>         possibly violating their rules for field-contents.
>
>
>
>     If my address is:
>
>        666 CAcert Avenue
>
>     who cares?  Microsoft's address is 1 Microsoft Way, after all :)
>
>     What happens if we violate the rules?  What are the rules? Who's
>     rules are they?
>
>
>             If CAcert finds the string, it interprets the string as full
>             authorisation that CAcert is entitled to issue certificates
>             for the domain.  
>
>         That sounds like you are talking about whois service,
>         but whois is similarly to DNS just a subsidiary service,
>         it's not the real thing.
>
>
>
>     OK.  Is there a big risk here?
>
>         The big problem I see here is that it just improves a bit
>          on the second-level domains, but it will most likely fail
>         for third-level domains, since there is usually no whois
>         service for them.
>
>
>     Well, there is no *registry* service for third level domains.  This
>     is fine because we are showing ownership not control when we address
>     the registry.  Control is delegatable, ownership less so.  If I own
>     iang.org <http://iang.org> then I.also.own.all.the.subs.of.iang.org
>     <http://I.also.own.all.the.subs.of.iang.org>.
>
>     In general...
>
>         It also doesn't solve the question of Email Addresses
>         or Jabber addresses, or any other service below DNS-second-level.
>
>
>
>     Right, there isn't a solution that fits all of the email addresses
>     that CAcert happens to deal with, I would guess. For people who are
>     just email users, then this does not cover it.
>
>     It works for some, those who own their domains, and it establishes
>     something for all of the activity of that domain.
>
>     BTW, what do you mean by Jabber addresses?  There is no doco about
>     them being special, so they must be the same as email addresses?  Or?
>
>
>             We won't know which certs and for which domain, but we
>             already have strong systems to control that issue:  a domain
>             can only be added to one account, and if someone steals a
>             domain from another member, he'll have to face the Arbitrator.
>              
>
>
>             This will stop anyone playing games with Microsoft.com ...
>             because MS will never put that string in there, and I'll bet
>             they have taken good steps to stop people playing with their
>             registry entries :)
>              
>
>         But someone might do an MITM against their whois service.
>
>
>
>     Sure.  Or someone might shoot the owner, steal the laptop and then
>     pretend to be the owner while chatting to the boss.  Or...
>
>
>         Or someone might hack or social-engineer the whois servers.
>
>
>     Good.  Let's encourage them to do that.  Should leave some traces.
>
>     Meanwhile, the strength of the ideas is to use different methods
>     that by themselves are weak but together they work to raise the
>     barriers.
>
>         Ouch. I actually just tried a whois query against microsoft.com
>         <http://microsoft.com>
>         and was a little surprised by the result I got. (See attachement)
>
>         Whois isn't any more reliable than any other plaintext TCP
>         service on the internet.
>
>
>
>     Yes, the plaintext TCP request isn't any more reliable than any
>     other plaintext TCP request....  If any of the plaintext TCP
>     requests were reliable, then we wouldn't be having this discussion.
>      But they're not, so ...
>
>     That isn't the point.  The point is (partly) to diversify into
>     hopefully distinct weak methods that together, support a result.
>
>
>         microsoft.com <http://microsoft.com> is registered by tucows, so
>         Microsoft
>         obviously can't do much to secure Tucows (+Verisign?) whois servers.
>         And they obviously aren't very good in actually securing
>         the microsoft.com <http://microsoft.com> whois record.
>
>
>
>     Looks like it is an old issue, cerca 2000.
>     http://www.securiteam.com/securitynews/6D00L0K00G.html
>
>     Doing 'whois =microsoft.com <http://microsoft.com>' helps a bit but
>     it doesn't get the Registrant details.
>
>
>             Just throwing ideas around here....
>              
>
>         The problem I see is that the registrars do not have much
>         incentives to provide digitally signed or otherwise secured
>         access to
>         their database.
>
>
>
>     This is an an answer to an economics question that hasn't been asked....
>
>     The question right now is:  What can we do with what we have now?
>
>     iang