[dkim-dev] [ietf-dkim] Authorizing List Domains

Douglas Otis dotis at mail-abuse.org
Tue Sep 28 19:01:11 PDT 2010


  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





More information about the dkim-dev mailing list