On 9/28/10 3:27 PM, Murray S. Kucherawy wrote: > >> On Monday, September 27, 2010 4:19 PM, Douglas Otis wrote: > > > > TPA-Label involves ADSP being discussed on the dkim list. > > Unless you're talking about revising ADSP (which it seems you are > specifically not doing since TPA is meant to cover other > technologies as well; plus, ADSP wasn't in your list), we're talking > about something new that is not in the current DKIM WG Charter.
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. ... '--- > > Some have expressed strong desires to improve DKIM deliverability > > by allowing fallback to other adopted verification methods. > > TPA-Label permits such fallback without also requiring the same > > domain be used by alternative methods. > > The first sentence there seems contradictory to me; if you're > falling back to other methods, we're no longer talking about mere > DKIM deliverability. 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. > > DKIM is unable to unilaterally authorize third-party services which > > impedes use of restrictive acceptance criteria. > > DKIM specifically allows a domain to give a third party signing > authority by putting into the DNS a public key matching a private > key that is in possession of that authorized third party. Unless > there's an assertion being made that this mechanism creates a > hardship, I'm still not clear why that's been dismissed as a > possibility. Utilizing a discussion list and mitigating domain spoofing is not possible with existing ADSP assertions. Nor is publishing public keys for all such discussion lists either a practical or a wise solution. Inclusion of List-ID or Sender header fields as an ADSP compliance requirement places less reliance upon only the From header fields in the recognition of message sources whenever authorizing third-party services. > >> Since any client can say anything it wants for an EHLO > >> parameter, why should it be considered a type of authentication? > > > > The SMTP client identified by the EHLO might resolve the IP address > > used in the exchange. While such resolution is not required by > > SMTP protocol, it might offer an opportunistic means to > > authenticate the administering domain as a fallback method. > > 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. > For that matter, one could invent a scheme that mandates any piece > of data must match any other piece of data, both of which are > potentially (perhaps even often) under the control of a miscreant. > I'm not sure I see how this is useful. Requiring additional header field compliance better ensures different mail streams remain recognizable by recipients. Many MUAs already display Sender, 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. > Moreover, identification of a client as legitimate or otherwise > based on HELO/EHLO data has proven problematic if only because of > common configuration errors. Enforcing something along these lines > will likely create more operational problems than it solves. There is no assured authentication method specified by SMTP. This leaves a range of options that might be employed by third-party services, such as mailing-lists. However, ADSP's convention of only binding Author Domain DKIM signatures with the From header field disrupts these services whenever restrictive assertions are made. A goal of the TPA-Label draft is to leverage the strongest authorization method available. The strongest confirmed authentication method indicated within the TPA-Label for the domain in question reduces the receiver's discovery efforts. > > These header fields must match against TPA-Label specified > > domains. The contained domains ensure the effectiveness of message > > sorting or header display in allowing recipients a means to > > differentiate email sources that might also contain the From header > > used by ADSP. The source of these header fields must also > > correspond with specified domain and authentication/verification > > methods. > > ADSP makes a binding between the "d=" and the domain in the From: > field, the most visible of them all, and we've seen extremely narrow > use of this, much less success. I have doubts that expanding that > logic to other less common or less visible fields will see more > adoption or success. Few are willing to allow a few percent of their mail stream to be discarded just to mitigate domain spoofing. Those who have taken the extreme measure of asserting ADSP "discardable" did so after realizing a significant reduction in return business whenever recipients are not adequately protected against spoofing. By asserting "discardable", their domain is no longer able to exchange messages with most mailing-lists. Use of sub-domains or cousin domains is likely to create confusion and similar negative reactions driving away business when mailboxes become flooded with messages containing their new unrestricted domains. The goal of the TPA-Label draft is to allow consolidation on to a well protected email domain, where issues of unintended rejection or discarding are avoided. While this requires additional effort by the sender, the data needed to publish necessary exceptions is already available and can be used to populate a _tpa zone. :^) > I think if you're going to say a particular domain is authorized to > sign your mail and verifiers should consider such mail "good", then > you've already granted that domain the ability to pass your policies > through at least one vector. Constraining that domain to pass your > policies only one particular way doesn't gain you anything: Either > the domain is not compromised in which case everything's fine > anyway, or it does get compromised in which case the intruder can > simply generate malicious mail within the constraints of your policy, > and you're burned regardless of what policy you post. While many mailing-lists adequately exclude abusive subscribers, and properly confirm subscriptions, most simply redistribute messages as received, flattened, annotated, with header fields added. Annotations within the Subject line and message body, along with inclusion of specific header fields can be leveraged to discourage exploitation of authorized third-party services. This should offer far superior results over that obtained using SPF -all or ADSP discardable. The TPA-Label mechanism also offers a method to recover from damaged signatures whenever a path related authentication remains available and offers adequate protections. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
