cacert-sysadm AT lists.cacert.org
Subject: CAcert System Admins discussion list
List archive
- From: "Sam Johnston" <samj AT samj.net>
- To: IanG <iang AT cacert.org>
- Cc: Philipp Guehring <philipp AT cacert.org>, CAcert System Administrators <cacert-sysadm AT lists.cacert.org>
- Subject: Re: [Cacert-sysadm] CAcert email address snafu
- Date: Tue, 19 Aug 2008 18:45:00 +0200
- List-archive: <http://lists.cacert.org/pipermail/cacert-sysadm>
- List-id: CAcert System Admins discussion list <cacert-sysadm.lists.cacert.org>
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."
It doesn't work for email. It doesn't work for chat. It doesn't work for OpenID. It just works for domains and it's slow (WHOIS updates can be infrequent), unreliable (varies from TLD to TLD) and own't work for 2LDs and below, nor where the user of a domain is not the owner (it happens).
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. Ownership of the resource itself is, so far as I can tell, unnecessary for our security model.
Sam
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."
It doesn't work for email. It doesn't work for chat. It doesn't work for OpenID. It just works for domains and it's slow (WHOIS updates can be infrequent), unreliable (varies from TLD to TLD) and own't work for 2LDs and below, nor where the user of a domain is not the owner (it happens).
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. Ownership of the resource itself is, so far as I can tell, unnecessary for our security model.
Sam
On Mon, Aug 18, 2008 at 6:05 PM, IanG <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 | 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 then 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
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 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 whois record.
Looks like it is an old issue, cerca 2000.
http://www.securiteam.com/securitynews/6D00L0K00G.html
Doing 'whois =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
- Re: [Cacert-sysadm] CAcert email address snafu, (continued)
- Re: [Cacert-sysadm] CAcert email address snafu, Teus Hagen, 08/11/2008
- Re: [Cacert-sysadm] CAcert email address snafu, IanG, 08/11/2008
- Re: [Cacert-sysadm] CAcert email address snafu, samj, 08/11/2008
- Re: [Cacert-sysadm] CAcert email address snafu, IanG, 08/11/2008
- Re: [Cacert-sysadm] CAcert email address snafu, samj, 08/12/2008
- Re: [Cacert-sysadm] CAcert email address snafu, IanG, 08/12/2008
- Re: [Cacert-sysadm] CAcert email address snafu, samj, 08/12/2008
- Message not available
- Re: [Cacert-sysadm] CAcert email address snafu, samj, 08/17/2008
- Message not available
- Re: [Cacert-sysadm] CAcert email address snafu, samj, 08/17/2008
- Re: [Cacert-sysadm] CAcert email address snafu, Teus Hagen, 08/11/2008
- Message not available
- Re: [Cacert-sysadm] CAcert email address snafu, IanG, 08/18/2008
- Re: [Cacert-sysadm] CAcert email address snafu, Sam Johnston, 08/19/2008
- Re: [Cacert-sysadm] CAcert email address snafu, IanG, 08/19/2008
- Re: [Cacert-sysadm] CAcert email address snafu, Sam Johnston, 08/20/2008
- Re: [Cacert-sysadm] CAcert email address snafu, IanG, 08/22/2008
- Re: [Cacert-sysadm] CAcert email address snafu, Sam Johnston, 08/22/2008
- Re: [Cacert-sysadm] CAcert email address snafu, IanG, 08/28/2008
- Re: [Cacert-sysadm] CAcert email address snafu, Sam Johnston, 08/28/2008
- Re: [Cacert-sysadm] CAcert email address snafu, IanG, 08/29/2008
- Re: [Cacert-sysadm] CAcert email address snafu, Sam Johnston, 08/29/2008
- Re: [Cacert-sysadm] CAcert email address snafu, Philipp Guehring, 08/16/2008
- Re: [Cacert-sysadm] CAcert email address snafu, IanG, 08/17/2008
Archive powered by MHonArc 2.6.16.