Doug,
Firstly, this draft is not yet in IETF LC, so you've jumped the gun
a bit.
In any case, I believe you had, and took, a number of opportunities
to present your concerns at f2f meetings, on the list and in I-Ds
like the one cited below. However, you did not garner support
for your suggested changes. (Frankly, you didn't succeed in fully
explaining your concerns, at least I still don't quite get what
worries you.) But hopefully we'll get the benefit of IETF wide review
in the near future so maybe someone else will be able to see what
the DKIM list didn't.
Lastly, by "voting process," I guess you must mean the question I
asked after the end of WGLC, (thread at [1]). That wasn't a voting
process, it was me checking that relatively few WGLC comments didn't
reflect a lack of consensus, that the changes to handle the few WGLC
comments that were posted had been processed ok, and that there was
in fact no one at all on the list to speak up and agree with your
concerns. So, I checked, and we got a bunch of "+1" messages to
the effect that the draft was ready to send to the IESG and, so
far, zero messages agreeing with your position.
Stephen.
[1] http://mipassoc.org/pipermail/ietf-dkim/2008q3/010706.html
Douglas Otis wrote:
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