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

From: Douglas Otis <[email-masked]>
Date: Thu, 28 Jun 2007 21:29:49 -0700

This draft lays out what is destine to become email acceptance  
criteria based upon DKIM signing practices.  DKIM depends upon public- 
key cryptography and uses public keys published under temporary  
labels below a _domainkey domain that must be at or above the  
identity being signed to meet "strict" acceptance criteria.  Once SSP  
is deployed, those wishing to benefit from DKIM protections must  
ensure their messages meet the "strict" expectation of a signature  
added by a domain at or above their email-address domain.  This  
"strict" practice is the only significant restriction currently  
anticipated by these SSP requirements.

What is missing as a requirement in this document that would offer a  
practical means to facilitate meeting the "strict" requirement  
established by SSP itself.  Currently this requires either some type  
of undefined exchange of keys, delegation of a DNS zone at or below  
the _domainkey label, or a CNAME DNS resource record tracking an  
email provider's public versions of the public key they use, in  
conjunction with some agreed upon domain selector and the customer's  
domain reference placed within the signature.  None of these  
solutions are not either very practical or really all that safe.   
This approach also obscures who actually signed the message and on  
who's behalf.

There is a requirement that could offer a solution that is both safe  
and scaleable.  This requirement would remove any necessity to use ad- 
hoc exchanges of keys, delegation one's DNS zone, or setting up  
fragile CNAMEs coordinated at the customer's domain, tracking the  
selectors and public keys used by "authorized" email providers.  The  
requirement is to facilitate the authorization of "third-party"  
domains by name.  This can scale and would be far safer and easier to  
administer as well.

There is a draft that illustrates how this might work for SSP.

This draft 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

-Doug

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Douglas Otis <[email-masked]>
Date: Fri, 29 Jun 2007 16:00:13 -0700

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:

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