On 9/29/10 11:15 AM, Murray S. Kucherawy wrote: > > On Tuesday, September 28, 2010 7:01 PM, Douglas Otis wrote: > >> On 9/28/10 3:27 PM, Murray S. Kucherawy wrote: > > > > The TPA-Label draft offers additional ADSP assertions having > > semantics intended to support _existing_ mailing-list and > > third-party practices. The DKIM charter states the following: >>,--- > > Consider issues related to mailing lists, beyond what is already > > documented. ... >>'--- > > I believe the intent of that item is to document current MLM/DKIM > issues vis a vis already-published documents, as is done in the draft > that is currently a WG item. Extending ADSP or creating new > protocols doesn't seem to fit within that goal.
While done with the best intentions, the dkim-mailinglists draft in section 4.1 Author-Related Signing, recommendations should be considered a bad practice for domains being phished and making strict ADSP assertions. http://tools.ietf.org/html/draft-ietf-dkim-mailinglists-02#page-11 The motivation behind strict ADSP assertions is to mitigate damage caused when recipients are heavily phished. Redirecting phishing to unprotected sub-domains represents a bad practice as this will add to user confusion and dissatisfaction. Problems related to ADSP will not be resolved by permitting delivery of phishing attempts that purport to be from a sub-domain. At least the last sentence in the section admits only prohibiting use of mailing-lists is likely to be successful since any restrictive ADSP assertion will disrupt most of these informal third-party services. DKIM/ADSP can exclude delivery of deceptive messages that neither SPF or Sender-ID are able to reliably accomplish. Using ADSP with TPA-Label exceptions can also significantly reduce false positives by taking advantage of the strongest verification method available. This includes, but is not limited to, using DKIM signatures not within the Author Domain. As a secondary effect, domains making the only actionable restrictive ADSP assertion of "discardable" will find their email delivery integrity will suffer. In no small part, much of the damage to delivery integrity is caused by a unilateral change with ADSP assertion of "strict" to "discardable". This change was done with a mistaken belief DKIM signatures are not normally verified prior to acceptance. > > Sorry, should have said DKIM/ADSP deliverability, which is based > > upon DKIM Author Domain Signatures. The TPA-Label draft offers > > alternative ADSP assertions that indicate the possible availability > > of domain specific exceptions. When exceptions are not found, > > non-compliant messages are to be rejected, as opposed to being > > discarded or scored in some fashion. > > I'm confused. You say TPA allows fallback to other adopted > verification methods, but you also say it refers specifically to > DKIM/ADSP deliverability. I'm not clear on how both can be > simultaneously true. SPF authorizations fail more often than DKIM signature validations, but the percentages for either are not insignificant. As such, some domains would like path verifications to act as a fallback method whenever DKIM signatures don't verify. More than a third of business related domains publish the most restrictive SPF assertions that pertain to Mail From parameters, and only 0.3% of domains being heavily phished publish the most restrictive ADSP assertions that pertain to the From header field. As such, ADSP's inability to pass accountability to subsequent systems makes "simple" ADSP implementations incompatible with most third-party services. TPA-Label records give senders a means to recommend appropriate exceptions that are needed to overcome ADSP's accountability passing limitations. Without this ability, ADSP is likely to remain largely unpublished, and when published, not acted upon due to its high rate of false positives. > >> The DNSOP working group has repeatedly advised against use of > >> reverse DNS as a mechanism for client authentication. Do we claim > >> to have expertise they are lacking? > > > > See: > > http://tools.ietf.org/html/draft-otis-dkim-tpa-label-06#section-12.4 > > > > The SMTP EHLO or HELO hostname must resolve the IP address of the > > SMTP client. Reverse DNS is not used. > > I think that's a marginal improvement. Even if the HELO/EHLO > parameter can be resolved to the client IP address, that doesn't tell > you anything about the client other than it has control over some > portion of the DNS. Control of the DNS also identifies the DKIM administrative domain. In addition, verification of the SMTP client indicates which domain is actually introducing the message into the mail stream, where DKIM may not whenever a signature does not include an origination header field that matches the RCPT TO parameter. This difference becomes significant when dealing with replay abuse. > > Requiring additional header field compliance better ensures > > different mail streams remain recognizable by recipients. Many > > MUAs already display Sender, > > Which ones? None that I've ever used do. Perhaps you have not used Microsoft Outlook or did not recognize how the information is displayed, or haven't selected these headers in Apple Mail by using the viewing show header detail selections? Displaying these headers is not really necessary, as they are just intended to isolate different mail streams. > > and many who subscribe to mailing-lists already sort using > > List-IDs. Whether or not recipients see the required header field, > > their requirement helps isolate authorizations to specific mail > > streams, such as messages emitted by the authorized domain's > > mailing-list services. The TPA-Label response includes > > authentication requirements intended to exclude miscreants. The > > general premise is exceptional authorization is only given to > > trustworthy services. > > Again, I'm not seeing the utility here. If A can say "You can trust > that mail apparently from us and signed by B is authorized by us as > long as it bears a Sender: header field containing B", then an > intruder compromising B need only meet that requirement to be able to > send mail as A and have verifiers improperly trust it. No authorization scheme can fully mitigate problems caused when normally reputable third-party services become compromised. On the other hand, by overtly authorizing a third-party and leveraging their own authentication/verification methods, it remains clear which administrative domain needs to remediate a compromised system. This would not be the case had the Author Domain routinely published public keys for various third-party services, after also arranging to have unique selectors used by each of these services. It is also difficult to imagine a safe practice for widely distributing DKIM keys when such exchanges currently rely upon ad-hoc methods. The TPA-Label scheme avoids any exchange of key and selector information and always ensures the administrative domain of the third-party service remains apparent. > That you're catering to MUA display or sorting options only makes > that worse in my view. In any case, it's a tiny hurdle to overcome once > a penetration has occurred. Thus, there seems little gain here over > simply authorizing B to sign for A regardless of message structure. Required inclusion of specific header fields uses simple flags "S" or "L". These header fields ensure recipients are able to utilize more than just From header fields when determining the source of a message, such as those from various informal third-party services. Since mailing-lists are often unable to authenticate who issued the message, ensuring the means to isolate these mail streams represents an essential mechanism needed to discourage this weakness from becoming exploited. Another level of protection is afforded when most who now subscribe to mailing-lists already segregate these messages from other messages arriving in their inbox. The display of the header field is not always needed for the header field requirement to be an effective exploitation deterrent. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
