On May 26, 2006, at 2:00 PM, John R Levine wrote:
If a TLD used DKIM with 768 bit keys for example, that might be
adequate when this domain's messages are seldom targeted. On the
other hand, <big-financial>.<tld> may need to react to a highly
targeted attack employing greater resources, perhaps necessitating
1024 bit keys or greater.
This is a contract issue, not a technical issue.
Few entities are in a position to negotiate security details relevant
to DKIM keys within higher-level domains. Will ICANN include such
details within their security and operations criteria contracts? For
the convenience afforded blindly asserting parent signing is
authoritative for sub-domain email-addresses, are you suggesting
gTLD, ccTLD, and SLD domain service contracts should specify-
1) Permitted hashing, type and size of keys published for DKIM?
2) Retention period of keys published for DKIM?
3) Security of systems and MTAs that handle the private portion of
the DKIM key pair?
Should there be a paragraph in the base draft that lists these xLD
requirements separately?
There is a significant reduction in security in this regard when
parent signing is permitted.
That's simply untrue.
A domain name provider may be extremely proficient at securing domain
delegations and fulfilling SLAs. By permitting DKIM parent signing
to validate email-addresses within sub-domains, security lapses
wholly unrelated to DNS now impact entities well beyond their control
and perhaps even their knowledge. With DKIM parent signing being
considered authoritative, rather than as a third-party, one
compromised DKIM key can negatively impact security for an entire top
level domain.
A verifier should not expect any parent domain to be authoritative
for what is a valid sub-domain email-address. Annotations related to
the email-address should not rely upon baseless assertions by the
DKIM draft of an unconfirmed relationship. Confirming this
relationship may involve replicated information, but this information
also limits the scope of security risks. This extra information is
only required when third-party signatures are not sufficient.
A malicious or incompetent parent can make arbitrary changes to any
of its delegated domains.
If you consider a parent domain to be untrustworthy, its subdomains
have no security whatsoever regardless of any rules we might try to
invent.
So as I said, parent signatures are quite useful and have no
disadvantages.
A significant risk is created by the convenience sought making a
baseless assertion that parent signing is always authoritative for
sub-domain email-addresses. While a parent domain may be
authoritative in some cases, in many more cases this is not a valid
assertion. There is no dire impact disallowing this baseless
assertion. Either add the replicate information, or these messages
can still be signed by the parent domain, but viewed as being signed
by a third-party.
DKIM key management is not DNS management. This is like comparing a
doctor to that of a lawyer. You may trust them both, but for
different services. Insecure DKIM keys within a TLD or SLD domain
will cause a significant negative impact and will also make them a
prime target when employing DKIM.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html