[dkim-dev] [ietf-dkim] Authorizing List Domains
dotis at mail-abuse.org
Wed Sep 29 18:03:04 PDT 2010
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.
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
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
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
> >> 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
> 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
More information about the dkim-dev