Subject: Re: [domainrep] Web of trust (Tentative requirements list)

From: Alessandro Vesely <[email-masked]>
Date: Wed, 01 Sep 2010 13:26:32 +0200

On 01/Sep/10 01:05, Scott Kitterman wrote:
> On Tuesday, August 31, 2010 06:39:59 pm Douglas Otis wrote:
>>  Signing a message using DKIM MUST NOT be considered "taking
>>  responsibility" for actions of subsequent MTAs. After all, use of
>>  subsequent MTAs permit destinations to be modified, and messages
>>  replayed.  These actions are well beyond the control of the signing
>>  domain.

This is particularly true for public mailing lists.  DKIM alone does 
not allow to distinguish malicious replaying from normal expansion or 
forwarding.

>>  Reasons for using DKIM is largely to guard against spoofing the
>>  source of a message.   In the course of doing my job, I might send
>>  samples of messages used to entice victims to my colleagues, who then
>>  take the needed precautions.  However, if such a message were to become
>>  replayed and widely distributed, who would be acting irresponsibly? The
>>  entity initially sending the message, or those granted access to a
>>  subsequent MTA that allows destinations to be modified, and then
>>  replayed to large numbers of unskilled recipients?

IMHO, both, even if the latter is more guilty.  If the signed message 
was in a public mailing list, anyone could play the replaying, which 
is a reason for not signing messages to MLMs (but /this/ is off topic 
here.)

>>  Large domains might rate-limit accounts to protect their systems from
>>  being associated with bulk unsolicited email.  A bad-actor could
>>  establish a new account and then send themselves messages of which they
>>  intent to replay well beyond reason.   Once the large domain discovers
>>  the abuse, they will be unable to stop the campaign.  Why should the
>>  large domain offering low cost accounts be held accountable for abuse
>>  they can not be expected to control?

Because it accepted a questionable user.

> So I guess we should just give up on DKIM since it's useless as an input for
> reputation for anything else?

"Incomplete" and "useless" are rather different...

> In any case, this is off topic here, since assessing the reputation
> of domain is up to a reputation provider and not something we can
> standardize.

Which reputation provider?

I don't think we can reasonably expect that someone will reliably 
synthesize reputation data for each domain on the Earth.  First, they 
must have some input in order to do that.  Second, there must be a 
good number of them, since the number of domains is huge.  In order to 
standardize how such data is exchanged, we are better off knowing how 
the overall architecture is modeled.

The concept of "cooperative domain" is crucial here, as in FBL 
management.  Why would honest domains cooperate in order to abate 
spam?  As in the prisoner's dilemma [WP], they currently defect. 
However, given some infrastructure that allows their behavior to be 
monitored, they'd be better off cooperating.  (Social networks 
sometimes exemplify how to induce cooperative behavior.  For 
simulations see e.g. "Cooperation through communication: Agent-based 
models and experimental results" [DT].)

In case we are clever enough to work out a model that suits our needs, 
we'll be able to standardize all the required data exchanges. 
Nathaniel has identified five documents in the last sentence of [NB].

In case we are lazy, we should at least avoid to standardize something 
that precludes building a cooperative reputation system.  For example, 
we should provide for a flexible way of resolving who is the 
reputation tracker for a given domain.

-- 
[WP] http://en.wikipedia.org/wiki/Prisoner%27s_Dilemma
[DT] http://paduaresearch.cab.unipd.it/1910/
[NB] http://www.ietf.org/mail-archive/web/domainrep/current/msg00229.html

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 1 Sep 2010 07:52:56 -0400

> reputation tracker for a given domain.

I can see there might some potential benefit for reputation provider A to be 
able to reply "I don't have an opinion, but reputation provider B might."  I'm 
not certain how well such an operation would scale, but who knows.

Scott K

---

From: John Levine <[email-masked]>
Date: 1 Sep 2010 12:25:57 -0000

>not certain how well such an operation would scale, but who knows.

If we look at the closest thing we currently have to reputation systems,
DNS blacklists and whitelists, nobody does referrals.  In some cases one
list imports the data from another list, but you don't need a public
standard to do that.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 1 Sep 2010 10:02:02 -0400

On Wednesday, September 01, 2010 08:25:57 am John Levine wrote:
> >I can see there might some potential benefit for reputation provider A to
> >be able to reply "I don't have an opinion, but reputation provider B
> >might."  I'm not certain how well such an operation would scale, but who
> >knows.
> 

I agree. At this point I don't think it hurts to consider the idea, but I 
doubt it would ever get implemented.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 1 Sep 2010 11:56:45 -0400

On Mon, Aug 30, 2010 at 07:57:48AM -0400, Nathaniel Borenstein wrote:

> I'd like to view Allesandro's large and small queries in the context of long-term extensibility versus short term needs.  If we can create a good enough data model for reputation information, the small query (email system using DNS) could effectively express an interoperable subset of the large query (web-based systems doing arbitrarily complex stuff).  So, I find myself wondering: what is the fundamental unit of reputation exchange?

I really, really like this.  I think it's entirely the right way of
thinking about it, I think the basic outline of a reputon (which gets
points just on the excellent name) is about right, and I think this
will be a fruitful way to organize work.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 1 Sep 2010 14:44:41 -0700

> doubt it would ever get implemented.

+1, for all the reasons John described.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 01 Sep 2010 16:18:41 -0700

> will be a fruitful way to organize work.
Strongly disagree.  Good/bad ratings represent highly abstract 
information.  With such abstraction, it becomes impossible to reasonably 
aggregate the information being produced on an unknown basis, even when 
deceptively normalized over the same numeric range.

The data underpinning such abstractions can also be conveyed within 
small responses without needing to obfuscate their basis, such as when 
expressed as exponents.  Information could be reported as incidents of 
different categories of abusive behavior, together with speculated 
exchange rates (when available).  Reporting these two very different 
values as some abstract rating dramatically reduces the protective value 
of the information exchanged.  Network providers should be able to 
utilize their accurate exchange rate information and then aggregate the 
incidents reported to accurately assess their own networks, for example.

How an evaluation relates to the size of their monitoring against the 
speculated volume of exchanges emitted by a domain will very widely.  
Some will even inhibit bad ratings whenever a volume of transactions 
goes above some threshold to minimize support calls.  The requester of 
information should be encouraged to understand their own relationship 
with the specific domain, and to adjust their actions based upon 
reported changes of behavior seen in both increased incident rates and 
traffic volumes.   There is little to justify the use of abstractions.

It is also important that those reporting incidents, only do so when 
they have authenticated the domain as the source. The desire to use 
abstractions might be to avoid responsibility for any negative 
assertions being made.  This is bad when considering the repercussions 
caused when a domain becomes blocked.  Any domain should be able to 
defend themselves by avoiding abusive behaviors.  Incidents collected 
from assumed sources will strip these domains of such protections.

Social reputations might be expressed as being a member of the "big and 
venerated" club.  If a domain reputation service is to develop a "big 
and venerated" rating that is only able to punish smaller domains based 
on some scheme where smaller domains are unable to defend themselves, 
then of course an abstract rating could use just zero and one.  Larger 
domains already enjoy blocking protections caused by the resulting 
disruption that such action might create.

Large domains should still have all incidents reported to offer greater 
protections for security sensitive operations that may wish to improve 
protections based upon accurately reported incident information.  Of 
course, any requester would be expected to weigh incidents against 
speculated volumes, or perhaps their own volume measurements from their 
networks perspective.  For example, by having accurate incident 
reporting, a network would be better able to determine when they have 
become the focus of some attack.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 1 Sep 2010 16:21:08 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Andrew Sullivan
> Sent: Wednesday, September 01, 2010 8:57 AM
> To: [email-masked]
> Subject: Re: [domainrep] In search of the reputon
> 
> > I'd like to view Allesandro's large and small queries in the context
> of long-term extensibility versus short term needs.  If we can create a
> good enough data model for reputation information, the small query
> (email system using DNS) could effectively express an interoperable
> subset of the large query (web-based systems doing arbitrarily complex
> stuff).  So, I find myself wondering: what is the fundamental unit of
> reputation exchange?
> 

I like it too so far.

How do we feel about the basic "reputon" being a pair of scalars, one an expression of reputation and one of confidence in that reputation, say on a scale of 0 to 100?  (Just as a starting point.)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 1 Sep 2010 16:33:48 -0700

> Behalf Of Murray S. Kucherawy
> Sent: Wednesday, September 01, 2010 4:21 PM
> To: Andrew Sullivan; [email-masked]
> How do we feel about the basic "reputon" being a pair of scalars, one
> an expression of reputation and one of confidence in that reputation,
> say on a scale of 0 to 100?  (Just as a starting point.)

Sorry, that went out half-baked.

Given this:

> AGENT-A (identified with confidence level X) says that AGENT-B has PERCENTAGE likelihood (with confidence
> level Y) of ASSERTION.  (Some assertions will probably require encapsulating some arbitrary data as part of
> the reputon.)

AGENT-A is established by where the query lands, so it doesn't need to be part of the syntax at all.

AGENT-B is established as part of the query to AGENT-A, so it doesn't need to be part of the reply syntax.

PERCENTAGE is easy, a number from 0 to 100.

ASSERTION might be implicit in the query, but it might not.  So maybe it should be part of the syntax, or should be able to be part of the syntax.

Looking at the short case, I'm inclined to something like using the DNS to do this.  So maybe this, which is close to what John said early on, I think:

- send a DNS TXT query to <subject-domain>.<service>._rep.<rep-provider-domain> (<service> identifies the service about which reputation information is desired, e.g. "smtp"); this encodes AGENT-A, AGENT-B and ASSERTION implicitly (e.g. "behaves well")
- the reply contains only the PERCENTAGE integer

Where multiple services might be of interest, take advantage of caching and ask the question without ".<service>"; the reply would contain "<service>=PERCENTAGE[/Y][ ;<service>=PERCENTAGE[/Y] [...]]".

This is the minimum.  Other tag/value pairs, e.g. the NAICS stuff, could be included in the reply; recipients encountering such secondary data could/would/should just ignore it if they don't know what it is or don't want it.  What a reputation provider includes that is secondary to the minimum is up to it and its consumers to specify.

For the large query case, HTTP POST and XML with equivalent syntax would work for me.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 1 Sep 2010 16:34:33 -0700

> Behalf Of J.D. Falk
> Sent: Wednesday, September 01, 2010 2:45 PM
> To: [email-masked]
> Subject: Re: [domainrep] Web of trust (Tentative requirements list)
> 

+1 as well.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 1 Sep 2010 16:43:08 -0700

> Behalf Of Scott Kitterman
> Sent: Tuesday, August 31, 2010 4:06 PM
> To: [email-masked]
> reputation for anything else?  In any case, this is off topic here, since
> assessing the reputation of domain is up to a reputation provider and not
> something we can standardize.
> 
> [same sentiment repeated four more times]

Absolutely agree.  There are at least two anti-abuse vendors in here, and I don't think any of us believe standardizing our detection and filtering algorithms is a good idea, so I don't see how determining reputation is something that should be standardized either.

The IRTF has a draft about how to query an RBL, but there's nothing published about how one goes about populating an RBL.  Indeed it admonishes operators to be aware of the dangers of trusting part of their mail flows to the RBL operators' reliability.  I think that's the way it should be, and it applies to reputation as well.

Following that model, we should describe the query/response mechanism ONLY, as generally and usefully as possible, and not go any further.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 01 Sep 2010 17:14:47 -0700

> Absolutely agree.  There are at least two anti-abuse vendors in here, and I don't think any of us believe standardizing our detection and filtering algorithms is a good idea, so I don't see how det…
Nothing was said about standardizing detection methods.  Nothing was 
said about standardizing filtering algorithms.

Nathaniel suggested reputation information should be in a form that can 
be aggregated.  Such information needs to share a common basis, such as 
incident counts over time, or estimated exchanges over time, etc.

Any effort to standardize reporting a domain's reputation should at the 
very least include requirements that negative assertions (incident 
reporting) first authenticate the domain as being the source.  It should 
never be okay to make assumptions about which domain sourced a message.  
Such assumptions place smaller domains in greater peril, and is 
inherently unfair.

Is there any reason for not making domain authentication a requirement 
for incident reporting (the basis for reputation)?

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 1 Sep 2010 18:36:27 -0700

On Sep 1, 2010, at 5:14 PM, Douglas Otis wrote:

> Any effort to standardize reporting a domain's reputation should at the very least include requirements that negative assertions (incident reporting) first authenticate the domain as being the source.  It should never be okay to make assumptions about which domain sourced a message.  Such assumptions place smaller domains in greater peril, and is inherently unfair.

If a user of reputation thinks a Reputation Service is being unfair, they will stop using that service.  Just like today. That can't be built into a protocol.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 02 Sep 2010 02:13:25 -0700

> If a user of reputation thinks a Reputation Service is being unfair, they will stop using that service.  Just like today. That can't be built into a protocol.
A domain reputation service would not be limited to only email.   Do you 
really mean an RFC is unable to include normative language that 
specifies fundamental steps essential for ensuring domains are able to 
defend their reputation?
Without such advice, these systems might prove extremely

For example:

The source of unsolicited message incidents forming a negative 
assessment for a domain's reputation MUST authenticate the forward-path 
of the RCPT command as having originated from servers controlled by the 
assessed domain.  SMTP parameters are not covered in the DKIM signature, 
so only when signed To or CC header fields match the forward-path may 
the domain be considered authenticated for the purpose of assessing the 
issuing of unsolicited messages.  When there are no matching To or CC 
header fields or they have not been signed, then the DKIM signing domain 
MUST BE ignored for the purpose of assessing the issuing of unsolicited 
messages.

Instead, confirming that the EHLO host name resolves the SMTP client, or 
a TLS cert of SMTP Auth listing a DNS-IDs are possible alternative 
Authenticated domains suitable for unsolicited message assessment.  
Smaller domains might wish to utilize subdomains to sign their messages, 
and then use ADSP dkim=tpa-path to indicate how SMTP clients should be 
authenticated prior to acceptance, to better protect themselves from 
reputation services that might fail to authenticate the assessed domain.

-Doug