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

[Douglas Otis]

  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