Subject: RE: [ietf-dkim] Re: New Issue: TLD key publication and signing

From: "Markley, Mike" <[email-masked]>
Date: Tue, 14 Feb 2006 18:12:41 -0800

Frank Ellermann wrote:
> Hi, that sounds like a general "bug" or "feature" not limited
> to TLDs, it would be the same with say ac.uk or navy.mil SLDs,
> or any other domain with "independent" (zone cut) subdomains.

That's true, but domains under navy.mil are (presumably) operated by
subgroups within the organization that operates navy.mil. This is not
true of a TLD.

IMO, the ac.uk case is identical to the .com case, beyond having two
points (.ac.uk and .uk) at which a _domainkey record could be used to
assert the identity of another.

While I agree that the general case is interesting and should be
documented, I believe that there's (somewhat) more risk to the specific
case of a TLD (or second- and even third-level registrars), since those
are entities that are generally organizationally independent of the
domains within their namespace.

-- Mike
_______________________________________________
NOTE WELL: This list operates according to 
http://dkim.org/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Tue, 14 Feb 2006 18:25:57 -0800

> domains within their namespace.

   I remember talking about this a long time ago with Jim as a potential
   attack. While it remains so, a TLD operator can even more easily
   change your NS records too. So, really, the integrity of the DNS is
   hinged on TLD operators not doing such evil things. As such, I don't
   think DKIM's vulnerability is any greater than, say, the NS record
   for bankofamerica.com, right?

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Feb 2006 18:42:43 -0800

>   for bankofamerica.com, right?

Right.

DKIM uses the DNS for storing sensitive information.  The DNS already holds 
information sensitive to the useful operation of the Internet.

So I can't imagine that a DKIM threat analysis should be held accountable for 
discussing DNS exposures, other than to note that the correctness of DKIM 
information depends upon safe and secure DNS admin and ops.

Really, to say more strikes me as trying to boil the ocean.

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
NOTE WELL: This list operates according to 
http://dkim.org/ietf-list-rules.html

---

From: Peter Koch <[email-masked]>
Date: Wed, 15 Feb 2006 09:27:17 +0100

> domains within their namespace.

Hierarchy in naming does not imply nor necessarily follow hierarchy in
organization. It's a failure to ignore the feature of "delegation" by
assuming that something (== RR) attached to a domain name automatically
applies to all that name's descendants.
This has nothing to do with TLDs or TLD operators/registries being
or being considered malicious. It similarly applies to, say, a university's
naming scheme.

-Peter

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Feb 2006 12:34:55 +0000

>   for bankofamerica.com, right?

I think that that's correct. But this is a different threat, so we
should note it at least.

Stephen.

---

From: Jim Fenton <[email-masked]>
Date: Sun, 19 Feb 2006 23:28:51 -0800

> I think that that's correct. But this is a different threat, so we
Agreed.

If the problem were limited to TLDs, then we would be able to simply say
that the d= in a signature MUST NOT be a TLD.  But the problem isn't
just TLDs, but any parent domain, e.g., co.uk, ca.us, k12.ca.us, etc.

In response to some other comments, this isn't a DNS vulnerability.  DNS
could be perfectly secure and we would have this problem; it derives
from the fact that DKIM allows parent domains to sign for their
children.  So it belongs in the DKIM threats document.

I would probably rate it as a high impact (affects entire domains) but
low likelihood (one has to be the owner of a higher-level domain, and
most of them can probably be trusted not to do this) threat.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Mon, 20 Feb 2006 03:21:38 -0800

> children.  So it belongs in the DKIM threats document.

As much as I would like to completely dismiss any DNS-"related" attack to the 
DNS realm, and not DKIM's, I think your point is well-taken and should be 
documented, for the reason you give.

That said, I suggest a rather simple note:

      The nature of the DNS hierarchy gives quite a bit of power to any domain 
up the hierarchy.

      Once one has the ability to redirect the entire subtree to different 
servers, the rest of the attacks by a parent (or above) become quibbles.

d/
-- 

Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Feb 2006 07:22:43 -0800

Dave Crocker wrote:
>> As much as I would like to completely dismiss any DNS-"related" attack 
> to the DNS realm, and not DKIM's, I think your point is well-taken and 
> should be documented, for the reason you give.
> 
>      The nature of the DNS hierarchy gives quite a bit of power to any 
> domain up the hierarchy.
> 
>      Once one has the ability to redirect the entire subtree to 
> different servers, the rest of the attacks by a parent (or above) become 
> quibbles.

It should be noted that the only thing this affects is SSP.
A delegation cannot be overridden for selectors with the
exception of gross manipulation of NS records which is not
a dkim specific threat.

		Mike

---

From: Andrew Newton <[email-masked]>
Date: Tue, 21 Feb 2006 10:54:12 -0500

> exception of gross manipulation of NS records which is not

I guess I don't understand your point.

If the delegation of a domain name can be retargetted to another set  
of name servers, can't those name servers synthesize any necessary  
selectors such as with a wildcard?

I do agree that this problem is not specific to DKIM.

-andy

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Feb 2006 08:01:22 -0800

Andrew Newton wrote:
> If the delegation of a domain name can be retargetted to another set  of 
> name servers, can't those name servers synthesize any necessary  

Yes.

I had forgotten about the d= in the signature, but the point
I was trying to make is that with SSP, all a TLD would need
to do is install a policy and it would cover the entire
DNS space that doesn't have a more specific policy. Sort of
like Verisign's "site finder" :) Registrars wield a lot of
power in the DNS world...

		Mike