Here is a draft that outlines a few concerns for draft-ietf-dkim-ssp-06:
http://www.ietf.org/internet-drafts/draft-otis-dkim-adsp-sec-issues-03.txt
These concerns were not fully discussed on the DKIM list expect for
voting for an "as is". Unfortunately a voting process offers little
clarity.
There appears to be a factual error in the draft. Any restrictive
ADSP assertion such as "ALL" or "DISCARDABLE" creates an additional
requirement for what valid DKIM signature remains valid with respect
to compliance with ADSP assertions.
See: draft-ietf-dkim-ssp-06 Section 2.7. Author Signature
This section defines an Author Signature as a valid signature where
the "on-behalf-of" (DKIM signature i=value or its default) matches
against the From header field.
Section 3.2 ADSP Usage however says:
.----
|If a message has a Valid Signature from an Author Domain, ADSP
| provides no benefit relative to that domain since the message is
| already known to be compliant with any possible ADSP for that
| domain.
'----
Clearly, these two sections are in conflict. In addition, the Author
Signature definition is in serious conflict with the working group's
charter.
Since the DKIM key itself can assert a restriction upon the "on-behalf-
of" local-part, there might be some justification to generally require
signatures using local-part restricted keys to also match against the
From header field before being considered valid. It would be
dangerous to only impose this requirement based upon the existence of
an ADSP record. SSP attempts to use DNS "SERVFAIL" to detect an
attempt to block the ADSP records, but this status may not be apparent
behind a resolver. A conditional requirement is ill considered from a
security standpoint, and may even invite abuse.
Once the issue of restricted local-part keys is properly handled in an
independent fashion, then attempts to require the "on-behalf-of" match
against the From header field conflates DKIM and an ADSP record into a
poor replacement for either S/MIME or OpenPGP. After all, the DKIM
signature and it's "on-behalf-of" fields are normally invisible to the
recipient, and DKIM in conjunction with an ADSP still does not assure
control over the Display Name being seen. An MUA can always annotate
a message to indicate specifically what portions of the message match
against the DKIM signature's "on-behalf-of" and domain. The SSP
draft is conflating a valid DKIM signature and ADSP record into
becoming an assertion of the identity of the message's Author. Such
conflation clearly and dangerously exceeds the DKIM charter.
The underlying goal of ADSP was to afford a domain control over the
use of their domain within a From header field. This goal can be
fully met without stipulating that the DKIM signature be "on-behalf-
of" the identity within the From header field. The "on-behalf-of"
should relate to what the domain authenticated, even when the "on-
behalf-of" is opaque. It is common for what is being authenticated
by a provider to not be the email-address within the From header
field. Had SSP permitted an "ALL" assertion and a practice of the "on-
behalf-of" to opaquely or otherwise reflect what the signing domain
authenticated, then DKIM and ADSP would be effective at detecting Bot-
Net related abuse, the current email/Internet plague. Perhaps some
stats will soon be published regarding this concern. A link will be
published when ready.
It even seems SSP might be attempting to sabotage DKIM's anti-abuse
utility. There is no ADSP assertion that a domain is not used to send
or sign email, and ADSP "DISCARDABLE" at every node is how a domain
might wish to protect their hierarchy. Requiring the ADSP record to
also be below the "_domainkey" makes it impossible to also know
whether the domain does not publish DKIM public keys as well. Rather
than a term like DISMISSABLE, DISCARDABLE also implies that DSN can be
lost. SSP fails to even indicate that its assertions pertain to
SMTP. This lack of protocol specificity might therefore disrupt any
message where the From header field domain is not published in DNS as
a result of implied DNS existence.
-Doug
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf