ietf
[Top] [All Lists]

draft-ietf-dkim-ssp-06 in last call?

2008-10-08 15:21:17
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>