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