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

From: John Levine <[email-masked]>
Date: 17 Feb 2007 04:28:48 -0000

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?

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

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

---

From: Jim Fenton <[email-masked]>
Date: Fri, 16 Feb 2007 23:25:13 -0800

You didn't miss anything; this was an addition in the -10 version of the 
draft.  It was inserted in response to a Discuss concern expressed by 
Cullen Jennings in IESG review.

The concern we were addressing was that the ability for a TLD (or 
similar entity, such as .co.uk) to have keys published would give the 
power for a key to be very widely valid.  Consequently, if some sort of 
DNS or similar compromise were found that would make such a key appear, 
it would have a widespread impact.  Providing a way for the verifier to 
not accept keys published by TLDs and the like blunts the value of that 
attack.

In the example you gave, the existence of keys that are valid for the 
entire TLD should make other domains in that TLD nervous.  The g= tag 
only constrains the local-part of the address; there is no way to 
restrict a key published in a TLD to a particular domain or domains.  
The ability to sign for a subdomain applies to all subdomains, and is 
intended for use only when the subdomains are under common administration.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Sat, 17 Feb 2007 01:08:27 -0800

> blah._domainkey.com, why would those signatures be any worse than

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