Subject: [ietf-dkim] New issue: Signing by parent domains

From: Jim Fenton <[email-masked]>
Date: Wed, 12 Apr 2006 17:35:09 -0700

This issue derives from a conversation I had with Peter Koch at the end
of the week in Dallas.

In -base, section 3.5, the description of the d= tag allows the domain
of the signing entity to be a parent of the signing address itself.  In
other words, d=example.com and i=[email-masked] is legal.  This
was done largely as a convenience; it allows domains to sign using keys
at the higher domain level when they employ subdomains to aid mail
routing, rather than having to publish key records in each subdomain.

This gives rise to the attack described in -threats section 4.1.18, "Key
Publication by Higher Level Domain".  On one hand, this isn't a very
worrisome threat, since domains need to trust the publisher of their NS
records.  But it's possible to construct situations where this might be
a bigger concern.  For example, a higher level domain, not under the
same administrative control as its subdomains, starts signing messages
it sends on its own behalf, and a key is compromised.  All of a sudden
the subdomains are vulnerable too.  The problem is that there's no way
to tell where the administrative boundaries are between levels in the
domain hierarchy.

The solution to this would be to remove the language in section 3.5, "or
a parent domain of", and the threat goes away.

It seems like a small benefit we're getting through "parental" signing,
offset by a small threat.  How do others feel about this?

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

---

From: John Levine <[email-masked]>
Date: 13 Apr 2006 01:08:10 -0000

>offset by a small threat.  How do others feel about this?

There's no threat.  Despite a certain amount of wishful thinking to
the contrary, the design of DNS makes subdomains absolutely completely
under the control of the domains from which they are delegated.  If
you want to limit what the organization running your parent domain can
do, you do so by contracts and lawsuits, not anything technical.

I have always opposed making rules that can't be enforced, and a no
parent rule would be completely unenforcable since a parent domain
could, if so inclined, use any of a wide variety of techniques to
stuff records into subdomains anyway.

On the other hand, it's not hard to think of uses for parent
signatures.  For example, Time Warner's Roadrunner cable service is
organized into geographic regions with each region having addresses in
its own mail domain, such as [email-masked] here in central NY.
But they have one abuse desk for the whole company, so it's quite
plausible that they'd want to do the signing from rr.com.

R's,
John

---

From: <[email-masked]>
Date: Thu, 13 Apr 2006 07:55:48 -0400

As an ISP we route customer mail thru our mta's, we have business customers that may use their own mta's. If a customer determines that entity at foo.com wishes to use use bar.com's mta are you saying that bar.com should not sign on foo.com's behalf? Will that no present a problem with the reception of foo.com's mail down stream when dkim sigs are expected everywhere? How do we resolve that?
thanks,
Bill

-----Original Message-----
From: [email-masked] on behalf of Jim Fenton
Sent: Wed 4/12/2006 8:35 PM
To: IETF-DKIM
Cc: Peter Koch
Subject: [ietf-dkim] New issue:  Signing by parent domains

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Thu, 13 Apr 2006 06:09:32 -0700

On Thu, 2006-04-13 at 07:55 -0400, [email-masked] wrote:
>
> As an ISP we route customer mail thru our mta's, we have business
> customers that may use their own mta's. If a customer determines that
> entity at foo.com wishes to use use bar.com's mta are you saying that
> bar.com should not sign on foo.com's behalf? Will that no present a
> problem with the reception of foo.com's mail down stream when dkim
> sigs are expected everywhere? How do we resolve that?

This is a different problem than being signed by a parent's domain.  The
risks associated with the parent domain problem extends to general
access to the parent's signing servers, and not whether their private
keys were compromised because of the issue you raise.

The signing-domain is not responsible for the use of the email-address
per the i= parameter, especially in the case of the parent domain.  The
i= parameter should not permit inclusion of a sub-domain.  This
_assumes_ per-user constraints where i= values are not simply obtained
from the message for administrative convenience to "improve" message
acceptance.
  
-Doug

---

From: Jim Fenton <[email-masked]>
Date: Thu, 13 Apr 2006 15:41:36 -0700

> As an ISP we route customer mail thru our mta's, we have business customers that may use their own mta's. If a customer determines that entity at foo.com wishes to use use bar.com's mta are you say…
Bill,

This is a different issue entirely.  Currently, foo.com is automatically
entitled to sign for addresses in subdomains, e.g., [email-masked],
without any additional publication of keys.  This doesn't affect the
ability of foo.com to delegate authority to sign messages to bar.com.

So as an ISP, your customers would have the choice of signing messages
themselves using their own MTAs, or allowing you to sign messages for
them by publishing public keys (selectors) in DNS which correspond to
private keys you hold.  In any case, it's also OK for you to also apply
a signature as cox.com if you want, although for SSP purposes this would
be considered a "third party" signature since it isn't a signature on
behalf of the origination address.

-Jim

---

From: Peter Koch <[email-masked]>
Date: Sat, 15 Apr 2006 17:12:33 +0200

> under the control of the domains from which they are delegated.  If

quite the opposite is true, that's what delegations are for. I'd agree
it's not a threat - but a misconception. Hierarchy in naming does neither
imply nor follow hierarchy in administration (or administrative control).
Any attempt to set 'domain wide' defaults or values misses that fact.
It's related to "DNS tree climbing" or lessons (not) learned from RFC 1535.

-Peter

---

From: Dave Crocker <[email-masked]>
Date: Sat, 15 Apr 2006 09:27:01 -0700

> It's related to "DNS tree climbing" or lessons (not) learned from RFC 1535.

Peter, I am not understanding your point.  Yes, it is essential to distinguish 
between naming hierarchy and administrative hierarchy.  However, the DNS has 
both, an administration up the tree does have complete power over the entire 
branch under it.  An obvious example is exactly the ability to re-direct that 
you cite.

Please explain.

d/
-- 

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