[ietf-dkim] base-09 8.13. Inappropriate Signing

[Douglas Otis]

,---
|8.13.  Inappropriate Signing by Parent Domains
|
|The trust relationship described in Section 3.8(Signing by Parent 
|Domains) could conceivably be used by a parent domain to sign messages
|with identities in a subdomain not administratively related to the 
|parent. For example, the ".com" registry could create messages with 
|signatures using an "i=" value in the example.com domain. There is no 
|general solution to this problem, since the administrative cut could 
|occur anywhere in the domain name. For example, in the domain
|"example.podunk.ca.us" there are three administrative cuts
|(podunk.ca.us, ca.us, and us), any of which could create messages with
|an identity in the full domain.
|
|  INFORMATIVE NOTE: This is considered an acceptable risk for the same
|  reason that it is acceptable for domain delegation. For example, in 
|  the example above any of the domains could potentially simply 
|  delegate "example.podunk.ca.us" to a server of their choice and
|  completely replace all DNS-served information. Note that a verifier
|  MAY ignore signatures that come from an unlikely domain such as
|  ".com", as discussed in Section 6.1.1(Validate the Signature Header
|  Field).
'---

Is automatically assuming all parent domains to be authoritative or that
large scale domain delegations and private key exchanges represent
acceptable risk?

This is wrong from both a security and a cost standpoint.

Is it really acceptable to have ad agency's MTA's contain private keys
for perhaps thousands of their clients?  Why is this risk acceptable
when it is unnecessary?  How can a verifier know whether to ignore
messages signed by "com" or perhaps "tokyo.jp"?  Who will publish the
now "unlikely" domains list?

DKIM can help reduce unwanted emails by _always_ having the entity
transmitting and signing messages publish keys within their _own_
domain.  DKIM signatures are not seen by the recipient, so there is
little justification for having signing domains always match that of
some email-address domain.  It is a simple matter for a domain contained
within a message to publish a record that authorizes the signature when
these domains differ.

The existence of a leaf can represent a sha1/base32 authorization of
"isp.com", for example. 

 hgssd3snmi6635j5743vdjhajkmpmfif._DKIM-F.example.com.

"isp.com" could use dedicated domains for particular customers, such as
"cust-0894.isp.com".  Use of customer specific sub-domains would isolate
their customer's authorizations without key exchanges or DNS
delegations.  There is no need for DNS domain delegations, private key
exchanges, or the assumption that all parent domains are authoritative.

DKIM signatures should indicate on who's behalf the message is signed,
even when domains differ.  This would minimize DoS risks by eliminating
any hunting for authorizations.  It should not automatically be assumed
the recipient wishes to only trust the From header, nor that a valid
signature always assures the validity of a From header source.  In the
case of a mailing-list, the Sender header might be trusted and assured
instead.

DKIM signatures are also likely to suffer from replay abuse.
Authorization of SMTP clients can bypass anti-replay protections, as
might be needed when DKIM is used for white-listing purposes.

An authorization scheme can easily accommodate multiple signing domains.
The DKIM base should be able to accommodate multiple email-address
identities within the DKIM signature.  This flexibility is needed to
deal with EAI extensions, and is easily supported by an originating
domain authorization scheme.

Allowing an authorization scheme to be safely used with the DKIM base
requires fairly minor changes to the base draft.  Importantly, these
changes remove the need for DNS delegations, private key exchanges, and
the assumptions that parent domains are authoritative. 

-Doug