Re: Last Call: draft-ietf-dkim-ssp-requirements (Requirements for a DKIM Signing Practices Protocol) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]