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