Re: draft-ietf-dkim-ssp-06 in last call?2008-10-08 22:11:57On Oct 8, 2008, at 2:28 PM, Stephen Farrell wrote: 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.) A praiseworthy goal of SSP, when widely adopted, would be as a mechanism to help limit the use of a domain in the From header field for email by requiring a signature by that domain. Unfortunately SSP extends this goal to an area beyond their charter. Who should cry foul? For a signature to be compliant with even the lesser of the two ADSP restrictive assertions, the signature's "on-behalf-of" or its default must match against the From header field, the message's author. Why is that? This contrived requirement prevents a proper use of the "on-behalf-of" field as a means to indicate what had been authenticated. This authentication information is needed to better deal with replay abuse without collaterally blocking the entire domain. The overhead of verifying two DKIM signatures will then be needed to accommodate an "on-behalf-of" not matching against the From header field. Also as a result, the signature associated with the From header field is likely to be a blank "on-behalf-of". Two signatures where one informative signature could have been employed is not being practical. Requiring a domain's message to include a signatures that is "on-behalf-of" of the From header field is a bad practice. This practice is wasteful. This practice is bad for the environment. There is nothing gained by a blank "on-behalf-of" value, except as a requirement to implement this very bad practice. As a rhetorical question, why would large domains not wish to give recipients any option other than all-or- nothing? Clearly the "on-behalf-of" the From header field compliance requirement gives larger domains a distinct and unfair advantage in this respect. Some large providers manage to control outbound traffic to where only 5% of their traffic is likely the result of Bot-Net or bad-actor related abuse. When considered within the context of a signature lacking meaningful replay abuse prevention, a blank "on-behalf-of" offers nothing to improve the situation. There is also a real danger where message annotations that are based upon the existence of ADSP record and a DKIM signature might be seen by recipients as an assurance the From header field has been validated. With the DKIM WG being within the Security Area, this should have been a concern, since ADSP compliance provides no other option than to have the DKIM signature be "on-behalf-of" the From header field. 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. My hope as well. I hope to see DKIM to offer a practical means for ushering in IPv6 email. IPv6 is soon too massive and soon too tangled to be properly handled by black-hole lists. 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. IMHO, the damaging decisions were not the result of mailing list discussions. When attempting to discern what lead to the decisions, little can be discerned from a long series of empty votes. The reference to voting was not about whether to go to last call. Of course, this too was rather typical. How is it that a statement of a factual error in the draft not find thoughtful discussion on the mailing list, other than a vote on some suggested fixes? The lack of reasoning goes to heart of the concern. When asked for how or why a critical decision was made, an ensuing discussion offer an assurance that the reasoning was principled. "You can always add two signatures" sounds too much like "Let them eat cake" from my perspective. -Doug 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 ADSPassertion such as "ALL" or "DISCARDABLE" creates an additionalrequirement for what valid DKIM signature remains valid with respect tocompliance with ADSP assertions. See: draft-ietf-dkim-ssp-06 Section 2.7. Author SignatureThis section defines an Author Signature as a valid signature where the "on-behalf-of" (DKIM signature i=value or its default) matches againstthe 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 alsomatch against the From header field before being considered valid. Itwould be dangerous to only impose this requirement based upon the existence of an ADSP record. SSP attempts to use DNS "SERVFAIL" todetect an attempt to block the ADSP records, but this status may not be apparent behind a resolver. A conditional requirement is ill consideredfrom 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 apoor replacement for either S/MIME or OpenPGP. After all, the DKIMsignature and it's "on-behalf-of" fields are normally invisible to therecipient, and DKIM in conjunction with an ADSP still does not assurecontrol over the Display Name being seen. An MUA can always annotate amessage to indicate specifically what portions of the message matchagainst the DKIM signature's "on-behalf-of" and domain. The SSP draftis 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 metwithout stipulating that the DKIM signature be "on-behalf-of" theidentity within the From header field. The "on-behalf-of" should relateto what the domain authenticated, even when the "on-behalf-of" isopaque. It is common for what is being authenticated by a provider tonot 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 relatedabuse, 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-abuseutility. There is no ADSP assertion that a domain is not used to sendor sign email, and ADSP "DISCARDABLE" at every node is how a domain might wish to protect their hierarchy. Requiring the ADSP record toalso be below the "_domainkey" makes it impossible to also know whetherthe 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. Thislack of protocol specificity might therefore disrupt any message wherethe 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
|
|
||||||||||||||||