[ietf-dkim] Domain ignore list in sec 6.1.1 ?

[Douglas Otis]

On Sat, 2007-02-17 at 04:28 +0000, John Levine wrote:
> I never noticed until now the text in 6.1.1 saying that an
> implementation can keep a list of domains that are "not valid signing
> entities".  I'm not suggesting we change it, but what was the idea of
> this paragraph?
> 
> If Verisign were to offer signing keys for mail from .com registrants
> (no doubt at extra cost) and published some keys at
> blah._domainkey.com, why would those signatures be any worse than
> anyone else's?

Security exponentially diminishes as the number of dependent systems
increase.  DKIM signatures are not expected to be visible to the
recipient, so who is trusted when a valid signature assures an
email-address?  When there is a security breach, what can the domain
owner of the email address do to restore protection?  In the case of a
of a SLD security breach, there are no contractual relationships or
restrictions with respect to DKIM signatures.

Would ICANN publish a list of "unlikely or unacceptable domains" to
allow the consistent configurations of DKIM verifiers?  Should "co.uk"
be able to sign?  How about "tokyo.jp"?  Who decides and how can
interchange be assured when no one really knows which domains are
allowed to apply a valid signature?  

The real problem with DKIM is that the signature can not indicate on
who's behalf it is applied when the email-address domain differs from
that of the signing domain.  In addition, there is no provision for the
email-address domain to authorize the signing domain in such a case.

A few minor changes is all that is needed to rectify the authorization
of signing domains and having the signature indicate on who's behalf it
was applied.  In which case, there would be no need to wondering which
about signature or authorization to check when assuring a specific
email-address.  The signing domain authorization would be explicitly
made by the email-address domain owner.  On who's behalf would be
explicitly made by the DKIM signature, even when domains differ.

The recipient would want to know that the email-address they trust has a
valid and authorized signature, whatever that might be.  An
authorization scheme would also permit multiple forms of EAI addresses
to be assured.  The recipient does not see the signing domain anyway.
If the signing domain has a problem, the domain owner of the
email-address can simply retract the authorization and seek services
elsewhere.

Why has DKIM avoided what should be a simple solution?  But then why
does Sender-ID need 100 transaction to keep SMTP clients nameless?  Why
is a group of providers attempting to write a BCP for block-list
operators that excludes the role of network providers?  Everyone wants
to send spam and blame someone.

Rather than having a domain name that might be recognized as an
immediate customer of a network provider, these schemes ensure millions
of other domains are likely to be used instead.  DKIM's inability to
identify on who's behalf the signature is applied, and allow the
email-address domain owner to authorize the signing domain will result
in ESPs warehousing thousands of private keys in their MTAs.

This security risk also includes that of any automatically authorized
higher level domain.  DKIM is carefully structured to wrest control from
the email-address domain owner to then hide the domain name of the
immediate transmitter of the message.  The immediate customer of the
network provider must be able to apply a signature using their domain,
even when an email-address domain might differ.  The network provider
should have AUPs that even stipulate this requirement, to ensure DKIM
assists in controlling abuse.

When "Big-Bank.com" authorizes "cust-311.isp.com" to sign their emails,
the recipient can still be assured that the email-address has a valid
signature.  If there is a problem, the authorized entity transmitting
the messages can be contacted, together with the email-address domain
owner.  "Big-Bank.com" could always autonomously add or retract their
authorization without any complex arrangements for tracking
key-roll-overs, handling private key exchanges, or setting up zone
delegations or leaf name redirection for public keys. 

-Doug