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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf