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

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

Michael Thomas wrote:
>    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?

I doubt that many nameserver implementations are querying Verisign's
nameservers for bankofamerica.com's A record directly, but rather for
the NS record. Even with that being the case, they could redirect the NS
request somewhere evil, the impact there is obvious breakage.

In the DKIM case, however, Verisign is able to quietly purport to be
bankofamerica.com without breaking anything in place (as they would if
they attempted to clobber our own _domainkey RRs, or redirect DNS
lookups elsewhere via rogue NS records).

Note, lest anyone get any funny ideas, that I don't actually think
Verisign would attempt this, and I'm not concerned for my personal
welfare as I doubly doubt they'd attempt it on a high-visibility target.
I just find them useful examples. You may substitute example.cn if you
prefer.

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

---

From: John Levine <[email-masked]>
Date: 15 Feb 2006 04:17:56 -0000

>lookups elsewhere via rogue NS records).

If I were an evil TLD registrar, I would have no trouble setting up a
few servers that mirrored the data on the real bofa servers with
nefarious records mixed in, and delegating your domain to them, so
that everything would look normal except for the stuff I deliberately
added or changed.  In fact, even though I am not (as far as I know) an
evil TLD registrar, I have stunt servers doing that sort of thing for
un-nefarious purposes now.

The entire structure of the DNS is based on successive delegations
from the root on down, and anyone above you can screw up your domains
any way he wants.  That's a feature, not a bug.

RFC 3833 already has a threat analysis of the DNS.  Please, let's just
point to that and be done with it.

R's,
John

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 15 Feb 2006 20:05:43 +0100

John Levine wrote:

> RFC 3833 already has a threat analysis of the DNS.  Please,
> let's just point to that and be done with it.

+1  

It would obscure real issues in threats-01 if all details of
doing interesting things with DNS are analyzed.  We can pick
an obvious worst case like "evil name server" as example, say
that DKIM isn't DNSSEC or ICANN or what else, point to some
relevant documents, and then focus on the real DKIM threats:

So far that's apparently replay, and attack from the inside.
As worst case their combination into "chosen message replay".

"Stolen key" and similar oddities are less relevant.  Bye

---

From: Douglas Otis <[email-masked]>
Date: Wed, 15 Feb 2006 11:49:12 -0800

On Feb 15, 2006, at 11:05 AM, Frank Ellermann wrote:

> It would obscure real issues in threats-01 if all details of doing  
> interesting things with DNS are analyzed.  We can pick
> an obvious worst case like "evil name server" as example, say that  
> DKIM isn't DNSSEC or ICANN or what else, point to some relevant  
> documents, and then focus on the real DKIM threats:
>
> So far that's apparently replay, and attack from the inside. As  
> worst case their combination into "chosen message replay".
>

This problem is _not_ related to DNS specific threats.  The concern  
is limited to whether the 'i=' referenced email-address can be allied  
with the signing-domain.  A TLD sending email from their domain would  
permit a vast number of email-address alliances with their signing- 
domain, when in reality, most such alliances would be invalid.  The  
TLD may have done _nothing_ wrong with respect to any DNS records or  
'i=' parameter.  If they do not have ultra-secure access to their  
outbound email, then a bad-actor could exploit a great number of the  
email-address, when the signing-domain is not the basis for trust.   
This would be especially true when an assurance is given the  
recipient based solely upon the email-address being within the  
signing-domain.

If the TLD was the bad actor, then again no DNS records would need to  
change for exploits to look extremely convincing.

s=some-key.example d=co.uk i=example.co.uk

When the TLD is a good actor, but their outbound access is not very  
secure...

s=some-key d=co.uk

With this signature lacking any optional 'i=' parameter, a vast  
number of email-addresses would be assumed allied with this signing- 
domain.

Example.co.uk is considered allied.  The default for 'i=' is *.co.uk.

-Doug