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

From: Michael Deutschmann <[email-masked]>
Date: Thu, 16 Sep 2010 17:15:29 -0700 (PDT)

Boy, this list has been noisy of late.

I've been too overwhelmed to pay attention to every message, but from
what I can see, it's a resurgence of the argument between those who
wanted ADSP/SSP to be simple and those who wanted "third-party signing"
support.  (Plus a third faction that just wants things to calm down.)

Now, at present, ADSP is near useless, because of the mailing-list
problem.  (And this is compounded by the ambiguity over what "all"
really means.)  The 3PS folks are citing this as a sign that the
simple-policy folks, who won before, were wrong.

But hold on a minute: The "third party signing" problem and the mailing
list problem are *not the same*.  The latter is a narrower use case.
It's not even a subset of literal "third party signing", since any
complete solution must accomodate third parties who *do not sign* ---
mailing lists that are completely DKIM-ignorant.

(Yes, I know any accomodation of legacy lists makes it much much easier
to pull off a successful forgery.  But as the alternative is
"dkim=unknown", it's no loss.  An intermediate signal, meaning that
mailing lists are the only way the signature can break, would be very
helpful to recipients who know what they are subscribed to.)

Sure, you can try to force all mailing lists to go through some signing
ritual.  But if the mailing lists were that willing to bend to
accomodate DKIM, they could already accomodate the published RFCs by
rewriting the From: on the messages they forward.

---- Michael Deutschmann <[email-masked]>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 17 Sep 2010 11:26:21 -0700

On 9/16/10 5:15 PM, Michael Deutschmann wrote:
>  ... The "third party signing" problem and the mailing list problem
>  are *not the same*. The latter is a narrower use case. It's not
>  even a subset of literal "third party signing", since any complete
>  solution must accommodate third parties who *do not sign* ---

Agreed.

>  (Yes, I know any accommodation of legacy lists makes it much much
>  easier to pull off a successful forgery. But as the alternative is

Review the TPA-Label draft.  The Third-Party Authorization specifies 
_how_ the entity can be authenticated using methods such as DKIM, SPF, 
EHLO, TLS, etcetera where the SMTP client should be identified to 
mitigate message replay abuse.  DKIM does not represent the best method 
to authenticate the SMTP client, however a cryptographic method for 
authenticating this source is needed to better cope with the IPv6 
environment.

The Authorization can also require inclusion of List-ID or Sender header 
fields before messages from this source are acceptable.   These 
additional requirements should help mitigate most of the risks related 
to spoofing with a message that visually appears to represent a 
distribution from a different source.  In the case of mailing-lists, 
recipients would be wise to sort list messages into specific folders to 
better ensure there would be less of an opportunity for deception.  
Likely, for most of those subscribed to a list, this is already a common 
practice.

>  Sure, you can try to force all mailing lists to go through some
>  signing ritual. But if the mailing lists were that willing to bend
>  to accommodate DKIM, they could already accommodate the published
>  RFCs by rewriting the From: on the messages they forward.

No need to force lists to change their behavior.  Instead, third-party 
services need to be characterized by zones containing TPA-Labels to 
allow administrators an easy method to convey their desires by simply 
pointing to such a zone.  For example, imagine MAAWG publishing their 
own TPA-Label zone.  The TPA-Label scheme allows email to gracefully 
transition to different authentication methods as they become 
available.  A domain may decide to sign using a subdomain just so they 
can signal which authentication method should be used for messages 
containing their Author Domain.

Once ADSP provides both comprehensive and actionable information, 
recipients will have a greater incentive to process this protocol.  
Recipients might even decided to check ADSP first, since a lack of a 
TPA-Label in conjunction with a ADSP dkim=tpa-path assertion can signal 
a message should be refused before any authentication is even attempted.

-Doug

---

From: Michael Deutschmann <[email-masked]>
Date: Sat, 18 Sep 2010 02:06:47 -0700 (PDT)

> Review the TPA-Label draft.  The Third-Party Authorization specifies

True, TPA does have support for identifying a DKIM-ignorant list based on
MAIL FROM:  (Although I don't see any support for sites that sign all
first-person-mail but are ignorant of user subscriptions.)

But, the problem I'm focusing on is that TPA is so much more complicated
than plain ADSP.  If a protocol was designed to just cover the mailing list
problem, it could likely be simpler.

The third-party signing use cases that do not overlap the mailing list
problem do not seem to be needed badly enough to justify the complexity,
IMO.  You could say 3PS in SSP tried to piggyback those costly yet
less-important cases on top of the mailing-list support, but the extra
weight caused the effort to collapse entirely.  Thus resulting in the
dead-simple yet hostile-to-lists ADSP.

---

From: Douglas Otis <[email-masked]>
Date: Sun, 19 Sep 2010 18:10:28 -0700

On 9/18/10 2:06 AM, Michael Deutschmann wrote:
>  True, TPA does have support for identifying a DKIM-ignorant list
>  based on MAIL FROM: (Although I don't see any support for sites that
>  sign all first-person-mail but are ignorant of user subscriptions.)

One should not authorize any service that redistributes messages without 
first verifying recipient subscriptions.  Many years ago we provided a 
database of IP addresses identified as non-conforming mailing-lists 
where the lack of subscription verification would lead to a listing.  
This represents a type of abuse unrelated to DKIM or message handling 
based upon asserted signing practices.

http://www.mail-abuse.com/enduserinfo_nml.html

Spammers would "subscribe" their victims to a mailing-list, and then 
submit their messages and have it redistributed by the mailing-list.

>  But, the problem I'm focusing on is that TPA is so much more
>  complicated than plain ADSP. If a protocol was designed to just
>  cover the mailing list problem, it could likely be simpler.

The idea behind the TPA-Label scheme is to place the burden (complexity) 
onto the sender.   When recipients make a transaction against a message 
not signed by the Author Domain they are provided _actionable_ 
information with authentication specifications needed to protect domains 
and brands.  Any sender able to offer this type of information would 
curtail a high percentage of any message spoofing, where recipients 
benefit from a reduction of spoofing within a minimal number of 
transactions.  The TPA-Label scheme also permits a graceful introduction 
of stronger, more efficient, and safer methods.  The TPA-Label scheme 
also allows this complexity to be handled by different entities from 
that of the sender, who might specialize on monitoring of third-party 
services, much as what was being done about 6 years ago when 
mailing-lists were being abused.

The TPA-Label scheme requires senders to be cognizant about where their 
messages are being sent, or to be reliant upon a service that tracks 
sender authentication and possible abusive sources.

>  The third-party signing use cases that do not overlap the mailing
>  list problem do not seem to be needed badly enough to justify the
>  complexity, IMO. You could say 3PS in SSP tried to piggyback those
>  costly yet less-important cases on top of the mailing-list support,
>  but the extra weight caused the effort to collapse entirely. Thus
>  resulting in the dead-simple yet hostile-to-lists ADSP.

Disagree.  The TPA-Label scheme can encompass E-invites, mailing-lists,  
and providers used by traveling users.  Restrictive ADSP/DKIM makes 
_any_ third-party service difficult to administer.  The TPA-Label scheme 
eliminates a bad practice of distributing private keys given to various 
third-parties where authorization becomes hidden.  Such transparent 
authorization makes it difficult to respond when a server becomes 
compromised, especially when this server handles messages for thousands 
of domains, which is not unusual.

Unlike transparent authorization, the TPA-Label authorization is able to 
mandate any desired SMTP client authentication and message elements that 
might be needed to ensure acceptance from legitimate sources and the 
proper message sorting.  When there is a problem, there will be less 
confusion about the actual source. With the TPA-Label scheme, problem 
sources and those responsible for confirming subscriptions remain 
apparent.  The TPA-Label scheme offers a graceful transition stratagem 
not predicated upon changes in how mailing lists handle their messages.

-Doug

---

From: Michael Deutschmann <[email-masked]>
Date: Sun, 19 Sep 2010 19:46:47 -0700 (PDT)

On Sun, 19 Sep 2010, Douglas Otis wrote:
> first verifying recipient subscriptions. [...]

But if the recipient site happens to have the information it would need
anyway to publish TPA on it's own, they can filter out such attempts
easily.  While they would be agnostic as to whether the putative sender
really subscribed to the list, they would know that the *recipient* isn't
subscribed and thus the message is bogus.

And they can do such filtering even if the putative sender publishes no
ADSP at all.  However, if ADSP is absent or "dkim=unknown", this
protection isn't worth much, since forgeries that make no pretension to be
list traffic must be presumed innocent.

And remember, many big sites will never compile the information needed to
display a complete TPA policy.  Without accomodation (ie: except-mlist),
"dkim=unknown" is all they can safely publish.

---

From: "John R. Levine" <[email-masked]>
Date: 19 Sep 2010 23:47:19 -0400

I think these all should be non-controversial.  Let me know if I'm 
mistaken.

1.  The overall amount of mail sent through discussion lists is small 
relative to direct (person-to-person) mail or to broadcast (one-to-many) 
mail.

2.  Lists do a good enough job of managing the mail that they forward that 
recipients generally do not worry about spam filtering mail from lists to 
which they've subscribed.  (Bozo filtering of legit but stupid messages 
doesn't count as spam filtering.)

3.  The most common way for spam to get into a list in recent years is for 
a subscriber's account to be stolen by a spammer who sends spam to 
addresses in the account's address book.

R's,
John

PS: I'm attempting to describe the way lists work now, not the way they 
might work at a hypothetical future time.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Mon, 20 Sep 2010 04:24:12 -0400

What do you conclude from this itemize list (which I *personally* 
happen to believe are true, but also recognize it is not exclusively 
true) from a design product development implementation standpoint?

Is this a feasibility study?

I'm interesting because we are very active right now in implementing DKIM.

See incline comments.

> relative to direct (person-to-person) mail or to broadcast (one-to-many) 

Relative. I seen it shift go back and forth.  For example, we have a 
list support list (1 to many) and platinum/priority support (1 to 1). 
  It shift as to the amount. I would like to focus on using DKIM for 
that later first beyond anything else, but in reality a list is really 
a kludge for a 1 to 1 (i.e. the delivery is still 1 to 1)

> doesn't count as spam filtering.)

+1, a managed list does a good job of not allowing non members to 
post. Filtering is done at a prior level, i.e. SMTP receiver.

However, we need to make sure that no IETF standard restrictive policy 
is allowed to submit or subscribe - that will be our implementation.

> addresses in the account's address book.

+1.  Compromised users are always a problem - at any level. IMO, 
focusing on this is at a different level.

> might work at a hypothetical future time.

+1, but if one is going to consider adding something new (DKIM) to a 
25+ years legacy software like a list server, then one needs to 
consider all the related hypothetical issues now and into the future.

While it might be feasible for some to not consider something, others 
are more proactive about product development that server others other 
than themselves and need to study it and ask the question "Are we 
ignoring a potential issue?  Maybe my system is fine, but what about 
others? What is best for me, best for others?"

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 20 Sep 2010 07:14:27 -0700

> relative to direct (person-to-person) mail or to broadcast (one-to-many)

That depends on the person.  In any event, how is the proportion of 
personal-to-group mail relevant to any topic of the working group?

> doesn't count as spam filtering.)

"do not worry...they've subscribed"
->
"have not produced a broad requirement for enhanced list performance of spam 
filtering."

> addresses in the account's address book.

I've no idea what the substantiation for this assertion.  It well might be true, 
but I'm not seeing how it is relevant to any topic of the working group.  (There 
is also likely to be a huge difference between lists that restrict posting 
rights and those that don't.)

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 20 Sep 2010 10:33:03 -0400

> personal-to-group mail relevant to any topic of the working group?

There's tradeoffs among optimizations for various scenarios, so I'd like 
to optimize for the ones that are most common.

> "have not produced a broad requirement for enhanced list performance of spam 

Sorry, I don't understand what that phrase is supposed to mean.  Enhanced 
how?  And like I said, I'm trying to describe what lists do now, not what 
they might hypothetically do at some future time.

> I've no idea what the substantiation for this assertion.  It well might be 
> true, but I'm not seeing how it is relevant to any topic of the working 
> group.

I'm describing what I've seen on the lists I manage and the lists I 
subscribe to.  It may not be statistically significant, but it's what I've 
got.  There's vast amounts of spam from random sending addresses, but the 
list software automatically rejects it all.

If spam comes from subscribers rather than from bad guys trying to 
impersonate them, there's no benefit from extra mechanism to keep out the 
nonexistent impersonators.

> (There is also likely to be a huge difference between lists that 
> restrict posting rights and those that don't.)

Well, there's another reality check:

4.  Most (nearly all?) lists restrict posting to addresses known to the 
list software, such as list subscribers.  Mail from other addresses is 
typically either rejected or sent for manual handling by the list manager.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 20 Sep 2010 07:42:29 -0700

On 9/20/2010 7:33 AM, John R. Levine wrote:
> Sorry, I don't understand what that phrase is supposed to mean. Enhanced how?

Better than is generally being done now.

>> true, but I'm not seeing how it is relevant to any topic of the working group.
>
> I'm describing what I've seen on the lists I manage and the lists I subscribe
> to.

Lousy sampling methodology.  And getting folks on this to agree with something 
based on the methodology has nothing to do with providing serious substantiation.

  It may not be statistically significant, but it's what I've got.

You are confusing data with information.  It's pretending that one person's 
experience is meaningful for making generalizations.  It isn't.  Ever.

> If spam comes from subscribers rather than from bad guys trying to impersonate
> them, there's no benefit from extra mechanism to keep out the nonexistent
> impersonators.

ack.

>> (There is also likely to be a huge difference between lists that restrict
>> posting rights and those that don't.)
>
> 4. Most (nearly all?) lists restrict posting to addresses known to the list
> software, such as list subscribers. Mail from other addresses is typically
> either rejected or sent for manual handling by the list manager.

Again, you are offering a reasonable hypothesis in the form of an 
unsubstantiated conclusion.

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Mon, 20 Sep 2010 17:09:09 -0700

> subscribed and thus the message is bogus.
It seems this is making two assumptions that are likely incorrect:

1) receiving domains know which mailing-lists their users have subscribed.

2) receiving domains reliably recognize mailing-list messages.

A sender benefits directly when accurate third-party information is 
available to receivers that help in preventing their Author-Domain being 
spoofed.

There is simply nothing that would suggest receivers are able to divine 
which third-party sources might have been legitimately used, and which 
can be trusted with respect to Author-Domain spoofing.

> list traffic must be presumed innocent.
Agreed.  This also needs to include non-participating list-traffic as 
well.  There will not be a flag day anytime soon where all mailing-lists 
will always act in accordance with some new convention.

> "dkim=unknown" is all they can safely publish.
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.  In addition, 
the TPA-Label scheme allows signatures of "big sites" that lack ADSP 
assertions to protect a different Author-Domain.  This protection 
requires control of the email-address be confirmed by the submitter.  
The TPA-Label scheme can represent concerted community efforts, 
organizations that specialize in providing third-party information, or 
information captured from user notification given to their submission 
administration.

-Doug

---

From: Michael Deutschmann <[email-masked]>
Date: Mon, 20 Sep 2010 18:35:37 -0700 (PDT)

> 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.
 
> 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.

"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.

> 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.

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.
Insecure mailing lists in private whitelist are at least obscure, but a
global whitelist cannot tolerate a single one.

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.

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.

---

From: Hector Santos <[email-masked]>
Date: Mon, 20 Sep 2010 22:31:18 -0400

> take care of the supposedly-via-list forgeries myself.

+1.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 20 Sep 2010 19:49:29 -0700

On 9/20/10 6:35 PM, Michael Deutschmann wrote:
>  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.

>  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.

>  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?

> > services, this still represents a finite dataset. In contrast,
> > the domains used by bad actors represent an infinite dataset.
>
>  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

---

From: Michael Deutschmann <[email-masked]>
Date: Mon, 20 Sep 2010 20:46:34 -0700 (PDT)

> Domains heavily phished are in a different situation.  For these
And nothing stops them from using full TPA, if they are willing to pay the
price.  But for most other domains, it's either except-mlist or unknown.

> authentication attempted.

TPA doesn't create authentication methods -- it documents whatever the
list already has.  If a list does not sign, and does not have a
predictable and SPF-protected MAIL FROM:, TPA cannot help.

If the list is "TPA-able", and the receiver site knows enough about it to
construct the TPA records, they can do just as strong verification.

> domains should compile a white-list for all mailing-lists?
Only in the same way that TPA constitutes the sender compiling a
white-list.

> How will fake SPF record be helpful?
I'm referring to the technique of, faced with an entity one wishes to
whitelist with no SPF record, constructing a best guess (based on past
behavior) as to what its correct SPF record would have been.  Then pointing
one's SPF validator at the fake record so long as the official result remains
"none".

Unacceptable false positive risk in my view, but it's hard for a forger
to beat.

> If they are happy with the results, why not?
If they don't cover every list their clients use, recipients will disable
incoming DKIM filtering to avoid false positives.  Everyone loses.

> Are ISPs normally phishing targets?
They aren't, but that doesn't mean I want to see messages forged to be
from their users.