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

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

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

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