This message is to summarize the issues and kick off a thread on issue
1265, "Signing by parent domains". The ticket can be viewed at
https://rt.psg.com/Ticket/Display.html?id=1265 (use username/password
ietf/ietf). Previous discussion on this topic is in the thread that
begins with http://mipassoc.org/pipermail/ietf-dkim/2006q2/003231.html
The issue boils down to whether the domain from which the public key is
obtained, specified by d= in the signature, must be exactly the same as
the domain part of the signing address (i=) or if it can be a parent
domain. In other words, if d=example.com and
i=user(_at_)sub(_dot_)example(_dot_)com, is
the signature valid or misformed?
So here are some of the issues:
Advantages of parent signing:
- Reduces need to publish duplicate copies of all key records for every
subdomain in existence.
- Suppose example.com has 20 signing MTAs (about Cisco's number), each
of which signs with its own key, and 5 subdomains which share the 20
MTAs. This means that 100 extra key records are needed to sign for the
subdomains, and when keys roll over another 100 new records are needed,
and then the original 100 are withdrawn. This is getting to be a lot of
duplicate records.
Disadvantages of parent signing
- Existence is the attack described in section 4.1.18 of -threats. For
example, publication of keys for .com which would be able to sign for
any .com domains would be worrisome, especially if such keys (which
would now be very valuable) were to be compromised. Many such domains
would not be pleased to learn that there is another entity that could
sign their messages. Restricting TLDs from publishing keys would not
help for situations like .co.uk or even .k12.ca.us.
- Increases exposure to DNS attacks at higher levels that might not be
otherwise detected by the subdomain.
Rebuttal:
- The parent domain ultimately controls the subdomain's fate through
ownership of its NS records, so a trust relationship has to exist
anyway. Any parent trustworthy to own a subdomain's DNS records is
trustworthy enough not to publish keys and sign maliciously, or to
mismanage any keys they do publish
More discussion:
- Peter Koch (who raised this issue initially) said on the chat that
"the problem...is less that the 'parent domain' ... would 'attack' their
children, but more that it would lead to defaulting up the tree."
I'm not sure what constitutes "defaulting up the tree" in this context.
Upward searches are never made for key records, because their actual
location is specified in the signature. If the key isn't at that exact
location, the signature is invalid.
- Concern that 'parent signing' could limit what the maintainer of the
parent zone could enter into their zone, since it could affect a part of
the namespace that was actually delegated out and in the hands of the
child zone maintainer.
I don't think such a namespace conflict is possible with DKIM. The
_domainkey separator between the selector name and the domain prevents a
key record published by a parent domain from conflicting with another
with the same selector name in a subdomain.
"nebraska._domainkey.example.com" can be different from
"nebraska._domainkey.sub.example.com"; which one you select depends on
whether d=example.com or d=sub.example.com
A suggestion:
Eric Allman suggests that one way of avoiding the problem is to use
CNAME records; for example:
_domainkey.sub.example.com IN CNAME _domainkey.example.com
I haven't tried this both with and without zone cuts between example.com
and sub.example.com, but if they're in a common zone at least, I can't
lookup a key record via a selector using the CNAMEd domain.
More discussion, please!
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html