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
_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev