[ietf-dkim] "third party signing" != "mailing list problem"

[Douglas Otis]

  On 9/20/10 6:35 PM, Michael Deutschmann wrote:
>  On Mon, 20 Sep 2010, Douglas Otis wrote:
> > It seems this is making two assumptions that are likely incorrect:
> >
> > 1) receiving domains know which mailing-lists their users have
> > subscribed.
>
>  Most don't. But such sites are also incapable of deploying TPA as a
>  sender. So that's just as good an argument for the impracticality
>  of TPA, as for the impracticality of except-mlist.

Domains heavily phished are in a different situation.  For these 
domains, there would be a strong incentive for offering third-party 
information, and they are more likely to know which third-party services 
are being used.  An except-mlist would likely cause phishing attempts to 
have List-ID headers included.  With these headers not being displayed, 
such an assertion would provide recipients little, if any, benefit.

> > 2) receiving domains reliably recognize mailing-list messages.
>
>  This also hurts TPA just as much. The only defense against forgery
>  of lists that can only be recognized weakly (by accepting unsigned
>  messages from any IP that display the correct List-Id:), is not to
>  subscribe to such lists.

Disagree.  A message not signed by DKIM therefore depends upon other 
authentication methods.  Within a single transaction, the TPA-Label 
scheme indicates whether an authentication method should be attempted 
for a domain, and whether the domain should be rejected outright without 
authentication attempted.

>  "except-mlist" comes out slightly ahead here. Since the subscription
>  whitelist is consumed where it is compiled, and thus doesn't need to
>  be converted into a standard "language" such as TPA, it can include
>  ad-hoc measures such as "fake SPF records" to limit forgery of
>  troublesome lists.

Sorry, but I am unable to follow this.  Are you suggesting receiving 
domains should compile a white-list for all mailing-lists?  How will 
fake SPF record be helpful?

> > Disagree. While there are many domains offering third-party email
> > services, this still represents a finite dataset. In contrast,
> > the domains used by bad actors represent an infinite dataset.
>
>  You seem to be hinting a global whitelist of mailing lists would be
>  feasable -- so the domains in question could just salute one and be
>  done with it.

If they are happy with the results, why not?

>  That doesn't sound practical to me. Especially since users at such
>  ISPs will likely subscribe to lists that are too insecure to be put
>  on the GW.

Are ISPs normally phishing targets?

>  Insecure mailing lists in private whitelist are at least
>  obscure, but a global whitelist cannot tolerate a single one.

For sensitive domains, third-party services will need to be closely 
monitored.  A requirement to include List-ID headers, for example, 
better ensures the messages will be unlikely considered something 
directed to a specific person.  Of course, nothing is absolute, but most 
mailing-lists are normally quick to respond to abuse.

>  Basically, the problem is that users at such ISPs do not want
>  protection from forgeries *of themselves directed at others* badly
>  enough to make the sacrifices needed to stop that cold. Such as
>  dropping a non-DKIM, non-SPF mailinglist where all their best
>  friends hang out.

The need for the scheme is to protect domains being phished.  When ISPs 
find their domain is being used to phish others, there might be some 
interest.  IMHO, this is not an immediate problem.  In addition, some 
third-party services might offer extremely strong authentication methods 
stipulated by the TPA-Label.

>  But, I want protection from forgeries *of other people directed at
>  me*, and the use of "dkim=unknown" or no-ADSP by those other people
>  hampers my ability to achieve that. I don't need them to go
>  whole-hog TPA, I just need help squelching the
>  supposedly-first-person forgeries, and I can take care of the
>  supposedly-via-list forgeries myself.

Preventing phishing requires comprehensive policy.  Gaps in this policy 
will provide little tangible benefit.  Again, you are assuming you can 
recognize all valid first-person and third-party exchanges?  BTW, the 
TPA-Label scheme is also able to secure first-person exchanges as well.

Your strategy places additional burdens on the receiver, but when they 
fail in some manner, the sender is likely harmed.  On the other hand, 
the TPA-Label ensures those who benefit make the added effort.

-Doug