Subject: [domainrep] Are we doing The Right Thing?

From: Alessandro Vesely <[email-masked]>
Date: Sun, 08 Aug 2010 09:18:57 +0200

Hi all,
there are various papers, of various practical vs theoretical tone, that 
describe issues of reputation and its relationship with the Internet.  The 
large majority of them aim at e-commerce issues, and the leid motiv is how to 
spread the knowledge that a given trader can be trusted by its customers.

With email it is the other way around.  We tag spammers' IPv4 addresses, but 
cannot do the same with IPv6 addresses or domain names, because there are too 
many.  The point is that, unlikely positive reputation, tracking negative 
reputation can be hampered by changing subjects' IDs.  A spammer can just 
change domain name.

In facts, considering the complement, or the negation, has always been a 
logic challenge.  Historically, it has lead to antinomies and contradictions 
in theoretical as well as practical fields.  Feedback loops are conceived as 
a channel for negative reports, and it is challenging to build positive 
reputations out of them.  I hope this list will find out how.

---

From: Douglas Otis <[email-masked]>
Date: Sun, 08 Aug 2010 23:35:32 -0700

On 8/8/10 12:18 AM, Alessandro Vesely wrote:
> Hi all,
> there are various papers, of various practical vs theoretical tone, 
> that describe issues of reputation and its relationship with the 
> Internet.  The large majority of them aim at e-commerce issues, and 
> the leid motiv is how to spread the knowledge that a given trader can 
> be trusted by its customers.
>
> With email it is the other way around.  We tag spammers' IPv4 
> addresses, but cannot do the same with IPv6 addresses or domain names, 
> because there are too many.  The point is that, unlikely positive 
> reputation, tracking negative reputation can be hampered by changing 
> subjects' IDs.  A spammer can just change domain name.
>
> In facts, considering the complement, or the negation, has always been 
> a logic challenge.  Historically, it has lead to antinomies and 
> contradictions in theoretical as well as practical fields.  Feedback 
> loops are conceived as a channel for negative reports, and it is 
> challenging to build positive reputations out of them.  I hope this 
> list will find out how. 
Alessandro,

Clearly, default positive reputation breaks down when there is an 
unlimited supply of alternative identifiers.  Your assessment that both 
IPv6 and domain names represent such a commodity of identifiers is 
correct, which do not lend themselves to reactive negative assessments.

Irrespective of whether a service attempts to make positive or negative 
assertions, domain reputation, with a possible exception of malicious 
content, must relate to the administrative domain running the server and 
issuing the message.  The fundamental criteria for deciding whether a 
message is abusive relates to whether recipients receive a reasonable 
level of benefit over that of the sender.  In other words, where the 
message is sent is often more significant than actual content, unless of 
course the content is blatantly abusive.

Gaming a reputation service can not be prevented when this service must 
forgive possible message replay aimed at causing harm to a different 
domain's reputation.  Such harm is permitted whenever the administrative 
domain running the server is ignored.  It also remains difficult to 
assess the level of recipients receiving a domain's messages compared 
against messages entering spam-traps.  Bot-nets often send messages to 
other accounts under their control, just to make such relative 
assessments increasingly difficult.

It is fairly typical for bot-nets to distribute email at slow rates 
through a large number of compromised accounts.  When the administrative 
domain signs their message stream using DKIM, this administrative domain 
is then able to determine, based upon messages entering spam-traps 
directly from their servers, which accounts are compromised.  A message 
with a valid signature entering a spam-trap does not offer irrefutable 
evidence which accounts are compromised, when the message entered the 
spam-trap from a different administrative domain's server.

Domains that have a good reputation can authorize different 
administrative domains to better ensure the acceptance of their messages 
that are utilizing these services.  If these administrative domains 
provide services to less reputable administrative domains, it might 
remain practical to grant acceptance based upon authorization, but only 
when the different message sources remain apparent to recipients.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Aug 2010 09:50:26 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Alessandro Vesely
> Sent: Sunday, August 08, 2010 12:19 AM
> To: [email-masked]
> Subject: [domainrep] Are we doing The Right Thing?
> 
> a

I think there are two discussions to have.  One is a lot easier than the other.

The two questions are (a) how to compute a reputation, and what that looks like; and (b) how to communicate a reputation.  The second question is strictly technical in nature and thus I believe squarely within the purview of the IETF as it will specify a protocol and invoke a transport mechanism.  The first is theoretical or mathematical and constitutes one implementation's "secret sauce", and I'm not convinced this is something the IETF needs to (or should) tackle, at least not yet.

Two different reputation vendors might approach things differently, one producing Boolean reputations and focusing on collection of data about only positive reputation sources, while the other produces a scalar reputation and focuses on reporting about negative reputation sources.  I don't think we should try to specify which is right; the right answer will be driven by market forces.

Even if there is a "right" algorithm, it's still not for the IETF to specify.  Although shortest-path-first algorithms are used in routing, for example, there's no RFC that specifies how Dijkstra's shortest-path-first algorithm is executed; there are plenty of mathematical texts for that.

In any case, domain reputation is the missing piece to make DKIM truly valuable; now that we have a verified domain name on a message, we need to be able to associate some value to it.  This will be that mechanism.

---

From: John Levine <[email-masked]>
Date: 9 Aug 2010 17:20:20 -0000

>The two questions are (a) how to compute a reputation, and what that
>looks like; and (b) how to communicate a reputation.  The second
>question is strictly technical in nature ...

Well, sort of.  We kicked this around at DAC for a while and didn't get
very far.  The sense I got was that there are two general sorts of
domain rep info, which I might call large and small.

The large one is analogous to your 27 page credit report, with all the
raw data.  You could imagine a rather large XML schema and some sort of
HTTP or SOAP query scheme to fetch it.

The small one is more like a FICO score.  The model I liked
represented it as three numbers.  The first was a quality score, with
a range of something like 0-100.  The second was confidence, how sure
you are that the quality is right, also 0-100.  The third was a NAICS
number, what kind of organization it was, on the theory that if you
know a sender is a bank or a government, you may be more willing to
deliver their mail than if they are a mail-order retailer.  That's
small enough to do as a DNS lookup.

While it's straightforward to specify the bits for either of these,
I'm not at all sure that either of them is actually what we want to
do.  It's a chicken and egg problem, it's premature to standardize
until we know what people will use, but people are unlikely to use
anything until there's a spec they can implement.

If you want, I can do an I-D for the short version.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Aug 2010 11:11:39 -0700

> From: John Levine [mailto:[email-masked]]
> Sent: Monday, August 09, 2010 10:20 AM
> To: [email-masked]
> Cc: Murray S. Kucherawy
> Subject: Re: [domainrep] large and small domain reputation
> 

We had the same problem with DKIM deployment and that didn't stop us.  :-)

My own experience suggests there will be consumers out there that want each of the two forms, and there will be a market for both.  There will be still others that just want a reputation provider to return a one or a zero.  My inclination, therefore, is to design a query mechanism that can cater to either form.  That lends itself nicely to HTTP and XML and such.

I'm wary of using the DNS for this, for all the usual reasons.

---

From: "John R. Levine" <[email-masked]>
Date: 9 Aug 2010 14:18:30 -0400

> We had the same problem with DKIM deployment and that didn't stop us.  :-)

Hey wait, we had DK and to some extent IIM.  For this stuff we got 
nothing.

> I'm wary of using the DNS for this, for all the usual reasons.

??

If it's a security question, the official IETF answer (and maybe finally 
in real life) is DNSSEC.  DNS has a lot of advantages if you're trying to 
do a query per mail message.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Aug 2010 11:24:37 -0700

> From: John R. Levine [mailto:[email-masked]]
> Sent: Monday, August 09, 2010 11:19 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: RE: [domainrep] large and small domain reputation
> 

No, more like the "That's not what the DNS is for!" resistance we get in the IETF.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 09 Aug 2010 11:27:17 -0700

> If you want, I can do an I-D for the short version.
Rather than being concerned about the query methods and attempting to 
extract history not provided by infrastructure supporting the domain 
name service, one solution might be to use TLS certs as a means of 
identifying the administrative domain of the issuing server.  The fact 
that a domain is large does not mean their messages are not potentially 
abusive.  There are tens of thousands of compromised accounts issuing 
spam individually at low rates within many of these large domains.  It 
would seem prudent to first understand what is needed to defend 
reputation rather than setting off to build an edifice on shifting sand.

Said another way, one of the most important decisions that needs to be 
made would be which identity has been adequately authenticated for the 
purpose of assigning administrative reputations.  While DKIM signatures 
offer a reasonable scheme when dealing with reputation in the positive 
sense.

However, to be effective, the reputation scheme would need to be 
automated to a high degree. Because DKIM messages can be replayed, and 
those authorized using SPF might actually be from different 
administrative domains, these weaknesses could be exploited to undermine 
a domain's reputation. Such a concern is not about dealing with any type 
of secret sauce, but is about which identities within email can be 
adequately authenticated and defended in some automated fashion.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Aug 2010 11:58:06 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Douglas Otis
> Sent: Monday, August 09, 2010 11:27 AM
> To: [email-masked]

For the sake of constraining the scope to something we could reasonably hope to accomplish, I think we should stipulate that we're only talking first about how to ask the question and get an answer.  We can cover (or decide not to cover) what question to ask later.

What's the consensus on this point?  I don't want to bite off more than we can chew, even before we're a working group.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Aug 2010 20:35:35 +0100

> What's the consensus on this point?  I don't want to bite off more than we can chew, even before we're a working group.

Not sure what you mean. Presumably interoperability for the protocol
to be defined here (is it still called CRAP? :-) is a goal, so won't
you need at least some basic question and answer that everyone can
handle?

S.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Aug 2010 12:54:23 -0700

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Monday, August 09, 2010 12:36 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]

For at least the first output of this group, I'm hoping to limit the problem-to-solve to just protocol, i.e. specification of how to ask a question and get an answer, versus which questions should be asked.  I think that confuses syntax with semantics and is best left to BCPs or other informational work.

There might also be different reputation services that answer different questions, like one service that's for evaluating DKIM "d=" domains, versus one for domains vetted by SPF, versus something else.  If our output is meant to be agnostic to such differences, we can't really discuss them at all.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Aug 2010 21:17:19 +0100

> For at least the first output of this group, I'm hoping to limit the problem-to-solve to just protocol, i.e. specification of how to ask a question and get an answer, versus which questions should…

Hmm. I guess I was thinking how you'd write a charter and the
above still seems odd to me at least.

> There might also be different reputation services that answer different questions, like one service that's for evaluating DKIM "d=" domains, versus one for domains vetted by SPF, versus something e…

Not necessarily. There may be some use cases that you do discuss,
a subset that are supported out of the box and some that could
later be supported via some sort of extensibility mechanism. You
do need to limit scope, but I'm not sure its really best to try
do that by ignoring the semantics of all use cases. (If that's
what you meant.)

(As a slightly irrelevant example, there's a decade-old thread
currently being regurgitated on the PKIX list as to the fact
that an OCSP result of "ok" can mean "cert was issued and not
revoked" or it could also mean "no such cert was issued" and
there's no way for an OCSP client to tell. Regardless of what
you think of PKI or OCSP, I think avoiding such things is good;-)

S.

---

From: John Levine <[email-masked]>
Date: 9 Aug 2010 20:20:36 -0000

>For at least the first output of this group, I'm hoping to limit the
>problem-to-solve to just protocol, i.e. specification of how to ask a
>question and get an answer, versus which questions should be asked.
>I think that confuses syntax with semantics and is best left to BCPs
>or other informational work.

I sympathize with your desire to limit our scope, but it's hard to
imagine a protocol that would be equally appropriate for a question
whose response would be a single bit and a question whose response
could be 400K of XML.

If people like my large and small models, we could use those as a starting
point, and just characterize the answers as arbitrary MIME blob and under
255 bytes of coded info.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Aug 2010 14:36:10 -0700

> Sent: Monday, August 09, 2010 1:21 PM
> To: [email-masked]
> Cc: Murray S. Kucherawy

That's not quite what I'm trying to limit.  I'm thinking:  Asking about a domain name's reputation should be in scope, but deciding how to pick which domain name to ask about should not be.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 09 Aug 2010 14:55:30 -0700

> That's not quite what I'm trying to limit.  I'm thinking:  Asking about a domain name's reputation should be in scope, but deciding how to pick which domain name to ask about should not be.
Will these implementation guidelines meet your expectations?

http://www.surbl.org/implementation.html

If not, why not?

Secondly, if the WG is to be prevented from defining where a domain in 
question is derived, what the results mean, and whether the information 
being relied upon for the reputation can be poisoned, then why should 
the IETF work on defining such a generic service lacking key protocol 
elements and security considerations.  Unlike a reputation based upon an 
IP address, applying reputation at the domain is potentially more 
disruptive.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 9 Aug 2010 17:55:32 -0400

On Monday, August 09, 2010 05:36:10 pm Murray S. Kucherawy wrote:
> That's not quite what I'm trying to limit.  I'm thinking:  Asking about a
> domain name's reputation should be in scope, but deciding how to pick
> which domain name to ask about should not be.

Similarly, I think what data is used to construct the answer should not be 
either.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Aug 2010 15:19:06 -0700

> Behalf Of Douglas Otis
> Sent: Monday, August 09, 2010 2:56 PM
> To: [email-masked]

No.

> If not, why not?

They specify how to choose which domain names to query.   As I said, I think that's not something this work should specify in a normative sense.  Including such discussion in Security Considerations of a document or in a separate BCP document would probably be fine.

Different reputation services might cater to different audiences (DKIM-asserted domains, SPF-asserted domains, etc.).  I don't want to nail this group's work down to just one of those.

> elements and security considerations.

I only said one of those things.  Also, your list nicely identifies DKIM (which signs a bunch of otherwise-unverified data), so you're suggesting the IETF shouldn't have done that work either.

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 9 Aug 2010 15:48:41 -0700

> whose response would be a single bit and a question whose response

If we look at the ~13 years of work on IPv4 reputation (including binary blacklist & whitelist output), I can only recall one example of the gigantic output -- and Karmasphere never really took off, though not for lack of brains behind it.

While it'd be out of scope to /specify/ which actions a Domain Reputation Client (DRC) may take on a message/connection/etc based on the answer provided by a Domain Reputation Service (DRS), it might be okay to talk about those actions at a high level to help set the scope of this project.  For example, a DRC handling DKIM-signed messages (where the identifier is the d= string) could:

1. reject after DATA (though that's rude according to SMTP)
2. generate an NDN
3. make a filtering decision, including but not limited to:
3a. discard it
3b. place in a specific folder, such as "inbox" or "spam"
3c. print it out so the user can stomp on it

There'd be a similarly limited list for other identifiers, such as domains in HTTP URIs in messages or in web browser requests.

Considering these as use cases (but again, not specifying actions) could help us keep the conversation focused so we don't end up with 400K of XML.

---

From: John Levine <[email-masked]>
Date: 9 Aug 2010 23:48:32 -0000

>1. reject after DATA (though that's rude according to SMTP)

It's 100% standards compliant.  RFC 5321 sec 4.5.2 even has a
discussion about it, noting that a reject after DATA means the
message is still the responsibiity of the sending client.

I know there used to be MTAs that behaved badly when confronted
with reject after data, but it was my impression that most of them
have been fixed.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Mon, 09 Aug 2010 21:55:30 -0700

On 8/9/10 3:19 PM, Murray S. Kucherawy wrote:
>> On Monday, August 09, 2010 2:56 PM, Douglas Otis wrote:
>>
Murray,

Sorry, but I am not sure I understand what you meant.  The surbl list of 
top level domains was done to constrain the DoS like effect that the use 
of random sub-domains might create.  Review the approach Google used for 
listing http related domains:

http://code.google.com/apis/safebrowsing/developers_guide_v2.html#ProtocolBasics

Their safe browsing protocol is based upon an http lookup.  Their 
service supports two category of lists: phishing and malware.  As Paul 
indicated, we offer a subscription service of this nature using a 
different type of client.  That said, their API requires clients to use 
assigned access keys.  Clearly, with such a control in place, it could 
support a subscription based service.

Their approach represents caching results from tree walking based upon 5 
domain levels in depth, which then returns a list of partial sha256 
hashes.  Partial hashes can then be subsequently queried for specifics 
at restricted frequencies. The code needed to access this service is 
included within the browser.

For email, centralized caching by a DNS resolver represents a typical 
mode of making requests against a reputation service.  Also, running an 
http client within an SMTP server might be viewed to represent a 
security concern.  So, how does one avoid walking the DNS tree when 
making queries against domains that may not be real?

The libidn service routines offer a list for the purpose of qualifying 
top level domains.  Perhaps the top level domain issue could be resolved 
using a separate service shared with many different protocols. Once the 
top of the name tree has been pruned, any tree walking at least starts 
with a query representing a possibly valid domain. With a constrained 
answer, this still leaves tree walking, and perhaps many round trips to 
obtain an answer.
> I only said one of those things.  Also, your list nicely identifies DKIM (which signs a bunch of otherwise-unverified data), so you're suggesting the IETF shouldn't have done that work either.
You suggested imposing more than just one scope restriction, but I don't 
wish to argue about this.  So allow me to apologize.  The query input 
used will have a significant affect on the stability of the service. The 
answer returned must also address specifics.  As an additional note, the 
rate phishing sites change exploited domains limits the benefits 
obtained from reputation when compared against a proactive approach such 
as ADSP dkim=all tpa-sig; :^)

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 10 Aug 2010 11:59:20 +0200

Murray S. Kucherawy wrote:
> question and get an answer, versus which questions should be asked.  I
> think that confuses syntax with semantics and is best left to BCPs or
> other informational work.

I thought this has been set up as a non-WG list in order to allow us to 
discuss semantic issues without being rushed for "real specs".

* who/why/when queries a domain's (or server's) reputation?
* how come the responder knows the answer?

Besides receiving messages, one may query reputation before filing abuse 
reports, or accepting an FBL subscription.

I agree we should avoid to specify the details of reputation algorithms, but 
we should clearly state what is their input and output.  If at all possible, 
I'd like better some sort of cooperative distributed open database than a 
number of opaque reputation vendors.

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 10 Aug 2010 10:19:39 -0400

> That's not quite what I'm trying to limit.  I'm thinking:  Asking about a domain name's reputation should be in scope, but deciding how to pick which domain name to ask about should not be.

BUT the domain MUST be authenticated, right?

-1 billion to using XML

+1 to use DNS (heck, Vixie is using it like a database, why can't we)

0 for not specifying the base of a secret recipe. There are a zillion
types of beers. They all have in common water, malt, hops & yeast. I'd
think an information doc may be useful.

-- 
Jeff Macdonald
Ayer, MA

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Aug 2010 09:43:36 -0700

> Sent: Tuesday, August 10, 2010 2:59 AM
> To: [email-masked]

I don't think one precludes the other.  I just want to keep scope creep in check.
 
> we should clearly state what is their input and output.

I do believe you're agreeing with me.

> If at all
> possible,

I believe any protocol a WG produces should be equally operable in either context.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Aug 2010 09:46:00 -0700

> From: Jeff Macdonald [mailto:[email-masked]]
> Sent: Tuesday, August 10, 2010 7:20 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> > That's not quite what I'm trying to limit.  I'm thinking:  Asking
> about a domain name's reputation should be in scope, but deciding how
> to pick which domain name to ask about should not be.
> 

So no reputation system may be queried if the message was unauthenticated?  That seems nonsensical to me.

> -1 billion to using XML

Why?

> think an information doc may be useful.

Sure, but I don't think that sort of R&D is the kind of work the IETF does.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 10 Aug 2010 09:52:09 -0700

On 8/10/10 7:19 AM, Jeff Macdonald wrote:
> On Mon, Aug 9, 2010 at 5:36 PM, Murray S. Kucherawy<[email-masked]>  wrote:
Email does not require a domain to be authenticated before email is 
accepted.  Unless a domain offers some form of authentication, a domain 
associated with abuse will not have been authenticated.

The term authenticate is often misused.  Some insist a server carrying a 
message for a particular domain considers the domain authenticated when 
the server in question is authorized by the domain.  In reality, often 
such servers handle messages for tens of thousands of domains.  
Authorization does not authenticate a domain as having originated the 
message.  Authorization is often used to "score" a message in 
determining acceptance, but it would be wrong to suggest authorized 
abuse should have a direct relationship with a domain's reputation.
> +1 to use DNS (heck, Vixie is using it like a database, why can't we)
Will all unknown domains be initially assigned a maximal negative rating?

If not, will it be necessary to walk a domain tree to find their parent 
domain?
> types of beers. They all have in common water, malt, hops&  yeast. I'd
I don't know what that means.

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 10 Aug 2010 10:22:15 -0700

On Aug 10, 2010, at 2:59 AM, Alessandro Vesely wrote:

> If at all possible, I'd like better some sort of cooperative distributed open database than a number of opaque reputation vendors.

That does seem to be a common perspective within the IETF, ASRG, and perhaps the open source community in general, and I can certainly understand why.  But I've worked on a number of reputation systems, and I can't imagine any way that a cooperative distributed open database could be useful -- simply because it'd be attacked constantly by people who want to (ahem) change their reputation.

For a standards discussion, however, shouldn't we be implementor-agnostic and try to create a protocol that can work for both the CDOD and the vendors, within reason?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Aug 2010 10:51:33 -0700

> Behalf Of J.D. Falk
> Sent: Tuesday, August 10, 2010 10:22 AM
> To: [email-masked]
> That does seem to be a common perspective within the IETF, ASRG, and
> perhaps the open source community in general, and I can certainly
> understand why.  But I've worked on a number of reputation systems, and
> I can't imagine any way that a cooperative distributed open database
> could be useful -- simply because it'd be attacked constantly by people
> who want to (ahem) change their reputation.

Vipul's Razor is a collaborative, open, spam classification system, and it's reasonably resilient to attacks (AFAIK).  It doesn't seem to me that a collaborative, distributed, reputation evaluation mechanism is too different.

I think we're headed for a world in which, like spam filtering is already, commercial and open solutions will coexist.

> For a standards discussion, however, shouldn't we be implementor-
> agnostic and try to create a protocol that can work for both the CDOD
> and the vendors, within reason?

+1

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Aug 2010 11:40:37 -0700

> point, and just characterize the answers as arbitrary MIME blob and

Seems like a reasonable starting point to me.  Any rough sketches you care to share?

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 10 Aug 2010 21:00:14 +0200

> Seems like a reasonable starting point to me.  Any rough sketches you care to share?

before we go any further, can we change the title of 'large and small 
domain reputation' into something different? At first glance the 'large' 
and 'small' seemed to be adjectives to the word 'domain', and not to the 
combined concept of 'domain reputation'. We're not talking about small 
domains or large domains, do we? So what would be a proper name to use?

/rolf

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 10 Aug 2010 15:08:44 -0400

> So no reputation system may be queried if the message was unauthenticated?  That seems nonsensical to me.

You lost me. A spoofed message with spoofed domains is perfectly
acceptable for input into a domain reputation system?

I'm coming up blank here what other word to use besides authenticated.
Maybe Doug has a point. Maybe authenticated isn't the right word but
it is the only one I can think of when referring to:

* A domain that passed DKIM verification
* A domain use by SPF/SenderID to verify that the connection IP is authorized

It seems like you saying there is no need for DKIM or any other
authentication system for a domain reputation system. Like I said, I'm
lost.

> Why?

bloat

-- 
Jeff Macdonald
Ayer, MA

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 10 Aug 2010 12:31:00 -0700

> acceptable for input into a domain reputation system?

A signing domain in an email message isn't the only reputation context.  There are also reputation systems which consider how likely an HTTP URI is to be pointing to a phishing site, and these are queried (as blacklists) by most (perhaps all) modern web browsers.

One of the reasons for this pre-WG discussion is to figure out whether the eventual WG (assuming there will be one) covers multiple contexts.  So far I think it can, but we'll have to be careful to be very clear in our language.

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 10 Aug 2010 16:02:57 -0400

> One of the reasons for this pre-WG discussion is to figure out whether the eventual WG (assuming there will be one) covers multiple contexts.  So far I think it can, but we'll have to be careful to…

Thanks for the clarification J.D. I'm a little confused on how a HTTP
URI could be treated the same as a domain. It would seem rather
trivial to cause a DoS to Google Docs by hosting some malware on it if
the path of the URI wasn't considered too.

I like to put out a data point. Food for thought.

We often have spam reports for email that we didn't send, yet it
contains a URI that we host. Lately these have been the URI of how to
add an address to email providers address books.

While this doesn't seem to be  a big problem today, I can see this
type of abuse growing. It isn't much different than an OpenRelay in
the sense that some other resource is being used without asking.

I suppose this may be out of scope. But I can see simplistic systems
in which a message which is deemed abusive penalizes all domains and
URIs. We've been forced once to change a host name because it was used
in forged email headers. I'd like to think that was a once in  a
lifetime experience. I'm hoping that whatever comes out of this group
we can keep it that way.

-- 
Jeff Macdonald
Ayer, MA

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Aug 2010 13:28:32 -0700

> Sent: Tuesday, August 10, 2010 12:09 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> > So no reputation system may be queried if the message was
> > unauthenticated?  That seems nonsensical to me.
> 

Sure.  Spam filters and various other security packages do it all the time.

> authentication system for a domain reputation system. Like I said, I'm

You might select the domain about which you want domain reputation by using the "d=" from DKIM or the domain that was the input to SPF, but is it appropriate for a domain reputation protocol definition to stipulate that this is a requirement?

> bloat

But its ubiquity (especially a deployed generate/parse code base) has no value?  I think that reasoning is an uphill battle.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 10 Aug 2010 13:52:11 -0700

On 8/10/2010 12:31 PM, J.D. Falk wrote:
> A signing domain in an email message isn't the only reputation context.
> There are also reputation systems which consider how likely an HTTP URI is to
> be pointing to a phishing site, and these are queried (as blacklists) by most
> (perhaps all) modern web browsers.
>
> One of the reasons for this pre-WG discussion is to figure out whether the
> eventual WG (assuming there will be one) covers multiple contexts.  So far I
> think it can, but we'll have to be careful to be very clear in our language.

I send email.  I have a web site.

These might entail two (or more) reputations or might entail one.  Ignoring the 
question of granularity, for the moment -- that is, different classes of 
information stream, such as personal mail from invoices -- is it reasonable and 
useful to group my reputation under a single score?

So, should the reputation for mail from bbiw.net be the same as for http://bbiw.net?

I think it should.  Or more specifically, I think that the service (mail vs. 
web) is not as important as the content type (personal vs invoice vs marketing 
vs...).

I could argue this the other way, but mostly I think that distinguishing between 
media is a gradation that isn't helpful.

This entire game is pretty coarse-grained, so distinctions should be made only 
when the pertain to likely differences in reputation that will be major.

I suggest that differential reputations should /only/ pertain to differences in 
content type (in the social sense, not the mime sense) and not with the means by 
which the content is conveyed.

Thoughts?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: John Levine <[email-masked]>
Date: 10 Aug 2010 23:19:06 -0000

>could be useful -- simply because it'd be attacked constantly by
>people who want to (ahem) change their reputation.

Perhaps someone from Cloudmark could say how well Vipul's Razor managed
to deal with that problem.  It's the openest rep system I can think of.

>For a standards discussion, however, shouldn't we be
>implementor-agnostic and try to create a protocol that can work for
>both the CDOD and the vendors, within reason?

It might be useful to spec something that organizations who already know
each other could use to exchange rep data, although it's not immediately
obvious why you'd need anything more than the ability to query each
other's database.

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Aug 2010 01:18:08 +0100

On 10/08/10 21:52, Dave CROCKER wrote:
> I think it should.  Or more specifically, I think that the service (mail
> vs. web) is not as important as the content type (personal vs invoice vs
> marketing vs...).

Interesting idea. What if you wanted to judge the reputation of the
coffee shop wifi supplier? Doesn't seem to easily map to a content type.
But maybe we really shouldn't have this effort look below the transport
layer.

> I could argue this the other way, [...]

I see what you mean. Me too. I'm not sure where I'd land on the service
vs. content type choice.

S.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 10 Aug 2010 20:11:55 -0700

> I see what you mean. Me too. I'm not sure where I'd land on the service

On further reflection, I realized that even what I appeared to be suggesting -- 
and possibly /was/ suggesting -- moves towards a multivariate labeling method -- 
  name plus some attributes -- for accessing a particular reputation.

And that's exactly what I /don't/ want to recommend.  I'd like to see a basic 
model that uses only a single value, namely the name.  If a name owner wants to 
differentiate reputations, use different names.  That's why some deity invented 
sub-domains.

d/
-- 

   Dave Crocker

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 10 Aug 2010 20:25:58 -0700

On Tue, Aug 10, 2010 at 8:11 PM, Dave CROCKER <[email-masked]> wrote:

> On further reflection, I realized that even what I appeared to be
> suggesting -- and possibly /was/ suggesting -- moves towards a
> multivariate labeling method --  name plus some attributes -- for
> accessing a particular
> reputation.
>
> And that's exactly what I /don't/ want to recommend.  I'd like to see a
> basic model that uses only a single value, namely the name.  If a name
> owner wants to differentiate reputations, use different names.  That's
> why some deity invented sub-domains.
>

Hi Dave,

Again, I'm not even sure what you mean.

Are you talking about e-mail w.r.t. domains?

We have a specific logic which understands how to "cascade" both up (to
subdomains in a URI) and down (to a URL path).

This is certainly easy to define in the public domain (e.g. IETF or
elsewhere).

Again, I'm sorry if I misunderstand your point, but subdomains shouldn't be
any real problem whatsoever with the properly specified logic and
signifiers (e.g. wildcards, other special characters, etc).

Also (and again), I'm trying to widen this issue to "domains" w.r.t. web
threats, not e-mail.

- - ferg

-- 
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawgster(at)gmail.com
 ferg's tech blog: http://fergdawg.blogspot.com/

---

From: Nathaniel Borenstein <[email-masked]>
Date: Wed, 11 Aug 2010 09:55:47 -0400

> Sure, but I don't think that sort of R&D is the kind of work the IETF does.

+1.  Moreover, this is one of the few areas where trade secrets -- often denigrated as "security through obscurity" -- can actually be quite useful over a limited time period.  Even more important, secret recipes are the kind of aspirational techniques that make investors open their wallets, a motivation which will be hard to counter with a few IETF documents.  -- Nathaniel

-----------------------------------
Nathaniel Borenstein		Chief Scientist, Mimecast
<[email-masked]>		<[email-masked]>
http://guppylake.com/nsb		http://mimecast.com