I have been asked to rewrite this for those not familiar with DKIM.
I'll try to keep it short.
The SSP requirements draft defines what is expected of SSP resource
records. Specifics are then to be defined within an upcoming SSP
draft. Simply stated, SSP DNS resource records are seen as a
mechanism to declare whether an email-address domain is "strict"
about complying with DKIM.
This SSP mechanism is desired by those wishing to exclude the
acceptance of "non-compliant" messages, which might often represent
phishing attempts. However, satisfying just anti-phishing goals
might create other pernicious problems.
What has _not_ been addressed in the SSP requirements is a
requirement to authorize third-party email providers.
This additional requirement would allow email-address domain owners
to unilaterally authorize their third-party email providers. Third-
party authorization would allow signatures within a third-party's
namespace to comply with expectations established by an SSP "strict"
assertion.
This "authorization" requirement was deemed unnecessary. There are
several methods for making third-party authorization "transparent."
"Transparent" authorization is accomplished by having the message
appear to have been signed by the email-address domain owner, rather
than by the third-party email provider.
For a DKIM signature, transparency is not essential. The signature
was designed to not be seen, where even visual examination will not
convey whether a signature is valid.
Currently, the only means to obtain "strict" compliance is with a
matching public-key at a "<selector>" below a '_domainkey' sub-
domain. This '_domainkey' sub-domain must also be at or above the
email-address domain. The email-address domain also locates the SSP
records.
In addition, keys and "<selector>" labels are to be updated on a
regular basis and a "<selector>" is not to be reused for a different
public-key.
To allow the DKIM signature authorization be transparent, a third-
party email provider can periodically request email-address domain
owners to:
1- Provide them their private-key, "<selector>" label, and the
location of their '_domainkey' sub-domain within their namespace.
2- Publish the third-party provider's public-key at a specific
"<selector>" and '_domainkey' sub-domain within their namespace.
3- Publish a CNAME RR pointing to a specific DNS location
containing the provider's public-key.
4- Delegate a zone of the email-address domain owner's domain that
is at or below the '_domainkey' sub-domain.
Note:
The CNAME RR will also need to be at a "<selector>" below the
'_domainkey' sub-domain within the email-address owner's namespace.
This CNAME RR must be at a location matching the "<selector>" and
domain used within the DKIM signature added by the third-party email
provider.
Transparent Authorization can lead to the following problems:
A- For scenario 1, 2, 3, & 4, transparent authorization does not
directly clarify who actually signed the message.
B- For scenario 2, 3, & 4, a compromised DNS server or poisoned DNS
record of the third-party provider might also compromise a large
number of the third-party's customer's public-keys.
C- for scenario 1, 2, 3, & 4, there is no simple method to relate
SMTP Clients with that of the DKIM signing domain to assist in
identifying possible replay abuse.
D- For scenario 1, 2, & 3, update procedures may not be available.
E- For scenario 1, 3, & 4, the third-party provider controls keys
that could be used for other purposes. Keys include user
limitations, suitable services, and Time-To-Live information.
F- For scenario 1, 3, & 4, the email-address domain owner is unable
to control local-part validations made by the DKIM Signature header
field's 'i=' semantics.
G- For scenario 1, a compromised third-party email server might
also compromise a large number of the third-party's customer's
private-keys.
Perhaps the greatest security concern could be that of C. DKIM has
made no provision to address possible replay abuse. An authorization
mechanism within SSP would help detect when replay abuse might be a
concern.
Some propose using an IP address path registration scheme as a
solution for replay abuse. The address path registration scheme, as
currently conceived, expands email-addresses using macros, including
local-part components. This methodology poses a serious DDoS concern
due to potentially very high amplifications that might be achieved.
By changing originating local-parts within a spam campaign, a DDoS
attack can be staged at virtually no cost to a bad actor. In
addition to macro expansion, wildcard schemes attempting to locate a
series of registration or MX records represents similarly high DDoS
risks.
Both transparent authorization or IP address path registration
referenced from an email-addresses diverts accountability away from
the public transmitter. Unfortunately, the public transmitter
represents an entry point for much of the abusive email now being
sent. Even with DKIM, due to possible replay abuse, the public
transmitter must still be held accountable.
When a large number of domains convey trust in a third-party
transmitter via explicit authorization, a greater tolerance can be
established. Explicit authorization rather than masquerading public
transmitters should be most able to reduce collateral blocking.
Explicit authorization also enables DKIM to ensure valid feedback is
sent to the cognizant domain whose IP address reputation would be
most at stake.
The draft that illustrates how this might work for SSP has not yet
reached the internet-draft directory, so here is a copy that can be
viewed now:
http://www.sonic.net/~dougotis/dkim/draft-otis-dkim-tpa-ssp-01.txt
http://www.sonic.net/~dougotis/dkim/draft-otis-dkim-tpa-ssp-01.html
If not yet published, here is also a functional link for draft-ietf-
dkim-ssp-00:
http://tools.ietf.org/html/draft-ietf-dkim-ssp-00
-Doug
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf