Subject: Last Call: draft-ietf-dkim-ssp (DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)) to Proposed Standard

From: Douglas Otis <[email-masked]>
Date: Tue, 25 Nov 2008 17:14:12 -0800

Recent changes did not correct concerns described in:
http://tools.ietf.org/id/draft-otis-dkim-adsp-sec-issues-03.txt

--o-- Changes meaning of DKIM's "on-behalf-of":

A highly detrimental aspect of this draft is its change to the meaning  
of RFC 4871's signature header's "i=" (on-behalf-of) value.

It uses "Alleged Author" as a term being checked by this mechanism,  
although DKIM is not to confirm the identity of the author.  As such,  
ADSP is in conflict with the DKIM WG charter!

Compliance with either "all" or "discardable" requires an "Author  
Signature".   This means the "on-behalf-of" value MUST match against  
the From header field's email-address (the Author), either explicitly  
or by being left blank.  This differs from RFC 4871 that specifies  
this field as containing the identity of the user or agent on behalf  
of which this message is signed.  RFC 4871 also requires this identity  
to be within the key reference domain.  RFC 4871's definition allows  
this field to indicate, even opaquely, the entity or account  
authenticated when the message was accepted for signing.

Being able to associate signatures with authenticated identities is  
essential in controlling abuse.  This ability is _absolutely_  
essential if DKIM's 'i=' and 'd=' is to form a reputational basis for  
IPv6 messages.   Abuse problems are commonly caused by compromised  
systems.  ADSP efforts at preventing forgery, even affirming the  
identity of the author, remains possible while also allowing the "on- 
behalf-of" value to _always_ represent an authenticated identity  
within the key reference domain.   Instead, the ADSP "Author  
Signature" definition requires that a signing domain "pretend" to have  
authenticated the Author, even when it may have been the Sender's  
email-address or some other account.  Compliance should only require a  
signature to use a key that is referenced "at" or "above" the email- 
address domain of the From header field.  Those domains that always  
indicate the identity, even opaquely,  that was authenticated will  
earn trust.  Authenticated identifiers can be used to mitigate replay  
abuse caused by any problematic domain granted access.  This approach  
also allows a provider a simple means to rehabilitate their  
problematic accounts.

--o-- Advising against wildcards for applications unrelated to ADSP:

This draft uses "_adsp._domainkey" to prefix a TXT records.  This is  
problematic for a few reasons.  Whenever a domain wishes to defend  
against unauthorized use, publishing  "_domainkey" sub-domains at ever  
existing DNS node becomes required.  As such, every node will appear  
to possibly contain DKIM public keys.  DKIM uses arbitrarily defined  
key selectors, where use of enterprise or carrier NATs may impair the  
protection of DNS cache.  By placing the "_adsp." prefix below the  
"_domainkey" sub-domain,  presence of the "_domainkey" sub-domain no  
longer indicates possible cache poisonings.  Scanning for possible  
poison using "_domainkey"  as the only known domain becomes  
impossible. :^(

The reason Dave Crocker gave for placing "_adsp" sub-domains below the  
"_domainkey" sub-domains used for keys was to facilitate domain  
delegations to DKIM email providers.   However, ADSP protection must  
be applied against every _existing_ node, where a delegation benefit  
therefore lacks merit.  This draft should instead depend upon the  
presence of discovery records defined by RFC 5321, and specify  
specific resource record types that contain the ADSP assertions, and  
not utilize prefixed TXT records to assert domain-wide policies.

This draft advises against use of wildcards, especially for publishing  
"(_adsp._domainkey.)*." TXT records.  However, not using wildcards  
represents a greater administrative effort.  Dependence upon NXDOMAIN  
versus NOERROR has also been problematic in the past.  These issues  
occur where ANY or AAAA cached records erroneously override the  
desired response.  The ADSP draft not only depends upon DNS, it  
mandates specific API error codes that potentially can impact email  
from any domain.

--o-- Prevents message addressing within From header field where the  
domain does not have records published within DNS:

Section 4.3's non-existence of email-addresses within DNS must be  
treated as a non-compliance with "all", or ADSP serves no purpose.

--o-- Anti-phishing protection requires loss of delivery status  
notifications:

The term "discardable" and its definition clearly indicates that RFC  
5321's concept of reliable delivery is to be ignored. However, if this  
mechanism performs its intended function, there should be little  
reason to relinquish NDNs.

--o-- Section 3.2 includes a factual error:

This section states that a valid signature by an Author Domain is  
known to be compliant with any possible ADSP for that domain.   
Compliance with ADSP requires an Author Signature, not just a  
signature by the Author domain (as it should have been defined).  If  
the intent of this draft is to accept all signatures by the domain as  
being complaint, compliance requirements should be explicitly stated  
as such, and not just indirectly implied.

This section also makes a factual omission.  It defines practices used  
by a domain, but then fails to specify which public transport protocol  
or protocols have adopted the advertised practice.  Misapplication of  
practice compliance assessments could lead to interchange problems  
when only a portion of the possible RFC 5322 related transports employ  
RFC 4871 and Author Signatures.

-Doug

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