ietf-dkim
[Top] [All Lists]

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

2010-09-29 20:06:25
  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