Subject: [domainrep] A sketch of a small query reputation system

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

Let's say you have a domain dubious.example, and you want to ask 
scorekeeper.example what its reputation is.  You do a DNS lookup of

dubious.example._rep.scorekeeper.example

Maybe it's a TXT record, maybe it's a new RR type.  If scorekeeper.example
has an opinion about dubious.example, it returns a record with three
numbers it it.  Perhaps they're space separated digit strings in a TXT
record, or three fields in a REPUTATION record.  They are:

Quality of domain: 0-99 with 99 being the best

Confidence of opinion: 0-99 with 99 being most certain

NAICS code: up to six digits, 0 if unknown, describing the type of
      organization

Note that NAICS is sort of like Dewey decimal, with longer numbers
being subclasses of shorter ones, so 92 is any government body, 922120
is a police department, 52 is a financial institution, 5221 is a bank,
522110 is a commercial bank, and 522130 is a credit union.

If you want to publish different opinions for different kinds of
domain usage, you give them separate names, e.g.

dubious.example._rep.mail.scorekeeper.example

dubious.example._rep.web.scorekeeper.example

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Tue, 10 Aug 2010 17:08:12 -0700

> dubious.example._rep.web.scorekeeper.example
John,

Does this approach assume scorekeeper.example uses wildcard expansion to 
capture random sub-domains used by bad actors at high rates?

What is the result when scorekeeper.example does not respond before a 
DNS timeout?

What is the result when scorekeeper.example returns no answer for a 
domain being queried?

How does scorekeeper.example score content for a user's web content, 
without also having this score applied against other web pages?

What NAICS like number will scorekeeper.example use for domains lacking 
ownership details?

Shouldn't scorekeeper.example return an epoch time for the period a 
domain belongs to the same owner?

How does scorekeeper.example defend their service from abusive clients?

-Doug

---

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

> NAICS code: up to six digits, 0 if unknown, describing the type of

Eh... what does the NA stand for there? (He asked rhetorically,
having just looked it up:-)

Fair enough that its a sketch but are you really proposing a
*regional* encoding of the type of *industry* as an abstract
way of classifying domain reputation? Seems like a bad idea to
me I have to say.

S.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 10 Aug 2010 20:17:33 -0400

> way of classifying domain reputation? Seems like a bad idea to

Perhaps NAICS isn't the best tool to use, but I do find the idea of what type 
of organization the domain is believed to represent is a useful data point to 
include.  I've done some analysis work in this area and for scalar reputation 
scoring, the value I would consider "Good" or "Bad" is different depending on 
the type of entity.  "Good" for a free webmail provider might well be "Bad" 
for a bank.

Scott K

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 10 Aug 2010 17:26:41 -0700

On Tue, Aug 10, 2010 at 5:17 PM, Scott Kitterman <[email-masked]>
wrote:

> Perhaps NAICS isn't the best tool to use, but I do find the idea of what
> type of organization the domain is believed to represent is a useful data
> point to include.  I've done some analysis work in this area and for
> scalar reputation scoring, the value I would consider "Good" or "Bad" is
> different depending on the type of entity.  "Good" for a free webmail
> provider might well be "Bad" for a bank.
>

Exactly. A scalar reputation scoring is absolutely necessary, I would
think.

And in fact, it would let the user of the service determine their own
"levels of badness" (or "levels of goodness") at the local level.

- - ferg

p.s I also noticed that you created (or presumably already had one) a
separate e-mail address (ietf-dkim@) for this list, which again compels me
to state that tying domain reputation *only* to e-mail/dkim/spf/whatever
issues is a very bad idea.

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

---

From: Douglas Otis <[email-masked]>
Date: Tue, 10 Aug 2010 18:08:51 -0700

On 8/10/10 5:26 PM, Paul Ferguson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, Aug 10, 2010 at 5:17 PM, Scott Kitterman<[email-masked]>
> wrote
Paul,

What works for email does not work for web traffic, unless the goal is 
to completely exclude a domain from being resolved within any type of 
exchange.  Having a millions of users walking your version of the dns 
name tree represent a fairly susceptible approach.

See:
http://www.theregister.co.uk/2010/08/09/dns_service_monster_ddos/

There is a different approach that might better achieves these goals 
when dealing with the worst of the worst.

ftp://ftp.isc.org/isc/dnsrpz/isc-tn-2010-1.txt

-Doug

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 10 Aug 2010 18:17:08 -0700

On Tue, Aug 10, 2010 at 6:08 PM, Douglas Otis <[email-masked]> wrote:

>
> There is a different approach that might better achieves these goals when
> dealing with the worst of the worst.
>

Hi Doug,

Yes, I'm fully aware of DNS RPZ -- that is *one* approach to an
*implementation* of "domain reputation" -- there are certainly many others
which do not use DNS as the  methodology (which I expect will be the most
contentious part of the entire proposal).

The point I'm trying to make -- and probably not too well -- is that the
scope of "domain reputation" is all over the map right now, and I urge
participants of this mailing list to not pigeon-hole "domain reputation" to
strictly an e-mail -centric issue.

Otherwise, I fear this effort will fail just as miserably as other e-mail
"reputation" systems that have come out of the IETF, with regards to
solving a real problem.

- - ferg

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 10 Aug 2010 21:20:44 -0400

> issues is a very bad idea.

Don't read too much into it.

Scott K

---

From: "John R. Levine" <[email-masked]>
Date: 10 Aug 2010 22:13:17 -0400

> way of classifying domain reputation? Seems like a bad idea to

I want some way to say "this is a bank" and as many other kind of 
organizations as possible, without reinventing this wheel.

It's true, NAICS is managed by the US census bureau, but so what?  I'm not 
aware of any other coding scheme that's as widely used.  If there is one, 
I'm happy to use that instead.

R's,
John

---

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of John R. Levine
> Sent: Tuesday, August 10, 2010 7:13 PM
> To: Stephen Farrell
> Cc: [email-masked]
> Subject: Re: [domainrep] A sketch of a small query reputation system
> 

Is an IANA registry a crazy idea?

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 10 Aug 2010 21:32:45 -0700

> Is an IANA registry a crazy idea?

Perhaps, yes.

Registry for what, exactly?

- - ferg

---

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

> From: Paul Ferguson [mailto:[email-masked]]
> Sent: Tuesday, August 10, 2010 9:33 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]

As a non-North-American-centric registry for business types.

---

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

> Behalf Of Paul Ferguson
> Sent: Tuesday, August 10, 2010 6:17 PM
> To: Douglas Otis
> Cc: [email-masked]

Actually I think John's proposal deals with this reasonably well.  A reputation vendor has the option of publishing reputation data about a domain at _rep.example, or subdividing the domain to be targeted toward various applications (_rep.mail.example, _rep.web.example, etc.).  Clients can query accordingly.

Trepidations about using the DNS aside, that seems pretty robust to me.

> "reputation" systems that have come out of the IETF, with regards to

Are you referring to RBLs, or something else I'm not aware of?

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 10 Aug 2010 21:38:21 -0700

> As a non-North-American-centric registry for business types.

I'm still missing your point, obviously.

What exactly would this accomplish, insofar as domain reputation is
concerned?

What prohibits bad actors from masquerading as legitimate entities? (That
already happens in the domain registrar space in a big way, BTW.)

I'm not following what you are suggesting, and what it would actually
provide. Please explain it to me like a grade schooler.

I don;t think a centralized db is, in any way, a possible solution to
domain reputation services.

I would also like to ask people to reconsider IODEF...

- - ferg

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 10 Aug 2010 21:40:29 -0700

> Are you referring to RBLs, or something else I'm not aware of?

No, I'm referring to DKIM, SPF, etc.

All of which have arguably failed to address the issues they were
originally designed to address.

- - ferg

---

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

> Sent: Tuesday, August 10, 2010 9:38 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]

It would satisfy the requirement a plurality of people have identified, namely not only knowing what the reputation of a domain is and confidence in that domain, but what category of business it represents.

> What prohibits bad actors from masquerading as legitimate entities?

I don't know how those numbers would be vetted.  I imagine that would be a product of the reputation provider.

> (That

I don't think that's news to anyone.

> domain reputation services.

OK, but I don't think that's what I was suggesting either.

How would IODEF, an incident reporting mechanism, be used to query a reputation service for information about a domain name?

---

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

> Sent: Tuesday, August 10, 2010 9:40 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> >> Otherwise, I fear this effort will fail just as miserably as other
> e-
> >> mail

Where or when did DKIM, SPF, etc. purport to be reputation systems?

> originally designed to address.

Arguably, sure.  But I believe the very premise of such an argument is in error.

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 10 Aug 2010 21:52:18 -0700

On Tue, Aug 10, 2010 at 9:45 PM, Murray S. Kucherawy <[email-masked]>
wrote:

>
> It would satisfy the requirement a plurality of people have identified,
> namely not only knowing what the reputation of a domain is and confidence
> in that domain, but what category of business it represents.
>

I'm not so sure that is actually true, nor possible. I don;t think there is
any reasonable way for any one particular entity to "categorize" or
"classify" a domain as belonging to a particular category.

Believe me when I tell you, it's a hellish task -- even SVM machine
learning is evolving to meet this demand (I know, we have engineers working
on this).

> a product of the reputation provider.

Define: reputation provider.

That's a loaded term if I've ever heard one. :-)

>
> How would IODEF, an incident reporting mechanism, be used to query a
> reputation service for information about a domain name?
>

IODEF is an extensible, XML-based system which can be used to exchange
information -- it just struck me as a very good way to exchange domain
reputation data. That is, after folks agree on the (preferably scalar)
ratings used to classify domain rankings.

$.02,

- - ferg

- --

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 10 Aug 2010 21:56:03 -0700

> Arguably, sure.  But I believe the very premise of such an argument is in

I don't think it is in error at all.

The very first instances of discussion on this mailing list were from folks
in the e-mail reputation "discipline".

Please connect the dots on your own.

Let's please not make that mistake again in this effort.

We have a real possibility this time to define & create something useful,
but if it gets hijack by anti-spam interests alone, I feel this will simply
divulge into another useless IETF exercise of vendors protecting their own
business models.

Cheers,

- - ferg

---

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

> Sent: Tuesday, August 10, 2010 9:52 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]

The US Census Bureau apparently disagrees.  This is precisely what NAICS is for.

> Define: reputation provider.

An agent that provides reputation services, namely the expression of estimation of standing of an entity based on its past observed behavior.  Within context, it's a service that provides a conversion between a domain name and a scalar (or some other data set) that expresses such an estimation, perhaps coupled with an expression of confidence in that estimation.

> That's a loaded term if I've ever heard one. :-)

Seems fairly straightforward to me.

---

From: John Levine <[email-masked]>
Date: 11 Aug 2010 05:05:30 -0000

>> It's true, NAICS is managed by the US census bureau, but so what?
>> I'm not aware of any other coding scheme that's as widely used.  If
>> there is one, I'm happy to use that instead.

>Is an IANA registry a crazy idea?

Well, yes.

NAICS is a list of about 1100 business types managed by the US Census
Bureau.  It really is North American, not just US like its predecessor
SIC, with input from the Canadian and Mexican statistical agencies who
also use it.  It's the result of a lot of effort by people who know
vastly more about categorizing organizations than any of us do.

For anyone who cares about this, here's the NAICS web site, where you
can look at all the categories:

    http://www.census.gov/eos/www/naics/

The UN has something called ISIC, but it seems to be much less widely
used, and looks awfully clunky.  Class 6190 includes dialup ISPs,
satellite base stations, and telecom resellers.  But central banks
have their own class 6411.

    http://unstats.un.org/unsd/cr/registry/isic-4.asp

R's,
John

---

From: John Levine <[email-masked]>
Date: 11 Aug 2010 05:10:12 -0000

> I'm not so sure that is actually true, nor possible. I don;t think
> there is any reasonable way for any one particular entity to
> "categorize" or "classify" a domain as belonging to a particular
> category.

So, just to be sure I understand you properly, you're asserting that
it's impossible to say that bankofamerica.com is a bank?  (That's
NAICS category 522110.)

In case it's not obvious, nobody expects to use AI to assign business
type codes automatically.  I expect to use a combination of manual
inspection and grep.

R's,
John

---

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

> Sent: Tuesday, August 10, 2010 9:56 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]

That wasn't my question.

None of the technologies you identified ever purported to be reputation services.  Indeed, the people working on DKIM have long identified reputation about a domain to be what DKIM needs to be truly useful.  The difference was acknowledged a very long time ago.  So to assert that DKIM (or the others) failed to provide reputation, something it never promised, is specious at best.

We're sunk from the get-go if we can't differentiate among things like authentication, authorization and reputation.

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 10 Aug 2010 22:13:56 -0700

>> there is

This is obviously *not* the U.S. Census, and you should be ashamed of
yourself for being so U.S. Government-centric. Really.

This -- first and foremost -- is an exploratory discussion list of the
IETF, which is not under the auspices of any government, nor is it
particularly answerable to any government.

Please do not be offended by my asking, but have you worked within the IETF
in the past?

> An agent that provides reputation services, namely the expression of
> estimation of standing of an entity based on its past observed behavior.
> Within context, it's a service that provides a conversion between a
> domain name and a scalar (or some other data set) that expresses such an
> estimation, perhaps coupled with an expression of confidence in that
> estimation.
>

There *cannot* be a single "reputation provider". That is why that term is
loaded.

It *must* be a multi-directional information exchange, and that is why I
suggested IODEF as the info exchange mechanism, It just works.

> Seems fairly straightforward to me.

No. Definitely not.

- - ferg

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 10 Aug 2010 22:18:10 -0700

> type codes automatically.  I expect to use a combination of manual

Hi John,

No it is easy to say bankofamerica.com is actuallt Bank of America is it
meets certain criteria (e.g. IP address, CERTs, etc.).

That's easy stuff. :-)

Can you tell me that bannkoamericainc.com.ru is real?

These are  the issue I'm driving towards, if you follow me...

- - ferg

---

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

> Sent: Tuesday, August 10, 2010 10:14 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]

It's not even available as an example of a mechanism for classifying companies?  You play by interesting rules.

Let's keep the theatrics to a minimum, please.

> particularly answerable to any government.

Nor was any such claim made.

> Please do not be offended by my asking, but have you worked within the

I appear to know enough IETF procedure to get this list created.  You do the math.

> There *cannot* be a single "reputation provider". That is why that term

I also didn't say there can be only one.  I expect a market of them to exist, just as is the case today.  I would like to see that grow.

> suggested IODEF as the info exchange mechanism, It just works.

That goes to how reputation is computed, and I submit that that particular issue should be out of scope, at least for now.

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 10 Aug 2010 22:22:03 -0700

> None of the technologies you identified ever purported to be reputation
> services.  Indeed, the people working on DKIM have long identified
> reputation about a domain to be what DKIM needs to be truly useful.  The
> difference was acknowledged a very long time ago.  So to assert that DKIM
> (or the others) failed to provide reputation, something it never
> promised, is specious at best.
>

Exactly.

DKIM is arguably a miserable failure, only that you trust a signature for
an entire domain which actually cannot be trusted. I see it every day.

I see domains with DKIM signatures sending spam, malware, and other trash.
So please explain to me what DKIM solves.

> We're sunk from the get-go if we can't differentiate among things like
> authentication, authorization and reputation.
>

That is exactly right, too.

Which is exactly why we are having this conversation.

Cheers,

- - ferg

---

From: "John R. Levine" <[email-masked]>
Date: 11 Aug 2010 01:24:23 -0400

> Can you tell me that bannkoamericainc.com.ru is real?

I have no idea, so were I to publish a reputation opinion about that 
domain, I'd make the NAICS code zero.

Do you really think that it's necessary to have accurate knowledge about 
every domain on the planet to have a useful reputation system?  Don't be 
silly.

R's,
John

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 10 Aug 2010 22:26:47 -0700

> It's not even available as an example of a mechanism for classifying
> companies?  You play by interesting rules.
>

What? The U.S. Government is suddenly the authority on what is a legitimate
business?

Please.

No *government* should be involved in domain reputation issues *ever* --
never.

> Let's keep the theatrics to a minimum, please.

Indeed.

> I appear to know enough IETF procedure to get this list created.  You do

Please accept my apologies on that -- I've been involved with the IETF for
almost 20 years, and I get a bit upset when I think technologies are being
"misdirected".

- - ferg

---

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

> every domain on the planet to have a useful reputation system?  Don't be

 Of course not -- don't be silly. :-)

However, there can always be a category of "unknown".

There can always be a category of "known malicious".

Etc.

Think beyond knowing everything.

- - ferg

---

From: John Levine <[email-masked]>
Date: 11 Aug 2010 05:32:59 -0000

>I see domains with DKIM signatures sending spam, malware, and other
>trash.  So please explain to me what DKIM solves.

Wow, this is like replaying greatest hits of five years of the DKIM
mailing list.

I think your question is answered reasonably well by the abstract
to RFC 4871.

R's,
John

---

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

> Sent: Tuesday, August 10, 2010 10:22 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> trash.

I suspect you, like so many others, appear to have put more faith in DKIM to be a silver bullet for solving spam or phishing than it deserved.  I think that's unfortunate, possibly a problem of hype and possibly a problem of bad early marketing on the part of its proponents, in either case establishing incorrect expectations.

But not one of these technologies ever claimed to be reputation systems, which is what you asserted.

DKIM does precisely what it claims to do.  The abstract of RFC4871 states it nicely.  I don't have any idea where you got reputation from that.  That it is a "miserable failure" because it didn't live up to that hype is certainly dramatic, but false.

DKIM and SPF mix authentication and authorization.  They connect to reputation systems nicely, but they are not themselves reputation mechanisms.

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 10 Aug 2010 22:38:06 -0700

John,

This is exactly why I don;t want to see an effort to define domain
reputation follow along the same line of thinking, since it is so much more
than that.

For real.

There is a real danger here of directing yourself (not necessarily *you*,
but an e-mail directed effort) into insignificance.

This has been the perceived relevance of various IETF efforts in the past
few years (which is why I haven't been to one since Prague).

$.02,

- - ferg

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 10 Aug 2010 22:40:36 -0700

On Tue, Aug 10, 2010 at 10:35 PM, Murray S. Kucherawy <[email-masked]>
wrote:

> I suspect you, like so many others, appear to have put more faith in DKIM
> to be a silver bullet for solving spam or phishing than it deserved.  I
> think that's unfortunate, possibly a problem of hype and possibly a
> problem of bad early marketing on the part of its proponents, in either
> case establishing incorrect expectations.
>

Actually, I don't care two bits about any either DKIM or SPF -- I'm not an
anti-spam person.

I'm a network security person.

Spam is manageable.

Malicious domains are only manageable when you start thinking about them as
they actually are -- crime.

Stop thinking about spam. Please.

- - ferg

---

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

> Sent: Tuesday, August 10, 2010 10:41 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]

I didn't see anyone trying to constrain any of this activity specifically to email or anti-spam.

Can we all play nice now?

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 10 Aug 2010 22:54:13 -0700

> Can we all play nice now?

Certainly! :-)

Having said that, I reiterate the need to look beyond e-mail -specific
technologies (e.g. DKIM, etc.) to play a role in domain reputation.

It's just a bad fit.

Let's open the playground to other possibilities -- e-mail has it's own
unique set of problems which are not share with, say, HTTP (et al.)
communicated streams.

Let's please keep that in mind.

Cheers,

- - ferg

---

From: SM <[email-masked]>
Date: Wed, 11 Aug 2010 01:02:01 -0700

>Please do not be offended by my asking, but have you worked within the IETF

Murray has been doing some work in the MARF WG and DKIM WG, and in 
the Applications Area.

There was a discussion about CRAP after the DKIM WG session at 
IETF78.  I don't recall whether it stands for Common Reputation 
Access Protocol or Convey Reputation Access Protocol.  This non-WG 
mailing list was created to follow up on the discussion.

Regards,
-sm

---

From: Paul Ferguson <[email-masked]>
Date: Wed, 11 Aug 2010 01:26:38 -0700

On Wed, Aug 11, 2010 at 1:02 AM, SM <[email-masked]> wrote:

> Murray has been doing some work in the MARF WG and DKIM WG, and in the
> Applications Area.
>
> There was a discussion about CRAP after the DKIM WG session at IETF78.  I
> don't recall whether it stands for Common Reputation Access Protocol or
> Convey Reputation Access Protocol.  This non-WG mailing list was created
> to follow up on the discussion.
>

For the record, I worked with various WGs in the 90's when I worked for
Cisco Systems, primarily in the routing area, since that was my forte.

Full Disclosure: I now work for Trend Micro, Inc., a security company.

Yes, we have our own reputation systems, however, we have properly (IMO)
split them into various systems, each of which can be correlated to one
another.

For example, over the past 4 years or so, we have built our own "domain
reputation" system. I won't go into the heuristics and logic that we use in
our secret sauce, but we have made a conscience  decision to make sure that
we treat "domain reputation" separately based on whether it is e-mail,
URLs, or malware.

But we correlate the date between all of them (e.g. "Show me all foo that
has bar").

In my mind, this is the true heart of domain reputation -- being able to
distinguish between the "foo" and coming up with a (scalar) score for the
"bar".

Bear in mind, industry is already doing this.

If we want to "standardize" in this area, we need to understand what we are
talking about.

And for the most part, the most pressing issue is not e-mail, it is URI
reputation.

- - ferg

---

From: Graham Murray <[email-masked]>
Date: Wed, 11 Aug 2010 09:59:32 +0100

> And for the most part, the most pressing issue is not e-mail, it is URI

Not forgetting that an email address can be referenced as a URI
(mailto:[email-masked]), so email reputation is a subset of URI
reputation.

---

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

> So please explain to me what DKIM solves.

At the first meeting in which we brought the DK and IIM teams together to begin the work that became DKIM, we discussed long-term strategy very explicitly.  We pretty much all agreed that DKIM's utility would be fairly low until it was supplemented with reputation systems, but that it was unwise to try to design both at once.  The current renewed interest in reputation systems precisely reflects, I believe, the fact that DKIM is finally "done" enough for many people to turn their attention to the next step.

Real progress against bad actors on the net will require several separate, mutually reinforcing new technologies.  If they are well designed to work together, the fact that they aren't very useful in isolation is no more relevant than the uselessness of any other stones of an arch in the absence of a keystone.

How about if we postpone the debate about whether or not DKIM is a failure until *after* we have it linked to reputation systems, as its designers always anticipated?  -- Nathaniel

---

From: Douglas Otis <[email-masked]>
Date: Wed, 11 Aug 2010 09:29:19 -0700

On 8/10/10 10:12 PM, Murray S. Kucherawy wrote:
> > On Tuesday, August 10, 2010 9:56 PM Paul Ferguson wrote:
> > The very first instances of discussion on this mailing list were
> > from folks in the e-mail reputation "discipline".
> >
>  None of the technologies you identified ever purported to be
>  reputation services.  Indeed, the people working on DKIM have long
>  identified reputation about a domain to be what DKIM needs to be
>  truly useful.  The difference was acknowledged a very long time ago.
>  So to assert that DKIM (or the others) failed to provide reputation,
>  something it never promised, is specious at best.
>
>  We're sunk from the get-go if we can't differentiate among things
>  like authentication, authorization and reputation.

Agreed.  Once one moves past domains related to phishing and malware, 
that leaves a _minor_ number of domains.  Once the truly malicious 
domains have been excluded, then web reputation must still deal with 
compromised web-pages, errant user accounts, etc.  The information 
needed to carry out that task, without disrupting an entire domain, 
needs to focus upon path elements in addition to that of the domain.  In 
either case, any query must use canonicalization to minimize the impact 
of random sub-domains on the service, and offer a way to restrict access 
to the service as a means to eliminate abusive clients.

Existing services demonstrate such anti-fuzzing efforts.

For email related query structures see:
http://www.surbl.org/

For web related query structures see:
http://code.google.com/apis/safebrowsing/developers_guide_v2.html

Note the _significant_ difference between these two strategies when 
dealing with different protocols having different exposures.

It is also naive to suggest this service can be directly achieved by 
publishing a DNS zone mapping the entire DNS into different categories.  
That ignores the portions of the Internet backbone that might be damaged 
when attempting to support such as service, and the level of support the 
service will require.

There appears to be an answer for what should be the first question.  
This answer needs no additional integration efforts for web or email.  
There is an open standard that describes a zone used to over-ride the 
resolution of domains, such as those involved with malware or phishing.

The issue of supporting the information contained is supported through 
information exchange efforts supported by:

http://www.cert.org/ietf/inch/docs/draft-ietf-inch-iodef-12.txt

If you look through the information being collected, it should quickly 
become clear it is focused on crime related details, and not what some 
related web-page or certificate might claim.  Frankly, criminal 
organizations can purchase the same infrastructure as those running 
legitimate services.  Invariably, when their domain is blocked, they'll 
complain as loudly as a legitimate enterprise requesting removal, 
especially when the blocking service lacks anything to backup their 
assertions.

Supporting assertions that led to a domain being blocked is not a 
trivial part of this process.  I understand why Paul is not interested 
in dealing with John Levine's suggestion of offering NAICS enumeration 
of business types.  Their job is hard enough categorizing the nature of 
the crime, without spending more of their time attempting to find a 
number for the type of criminal enterprise the US Census likely failed 
to categorize.

DNS is not good at exchanging details that are needed to sustain 
listings.  Because everyone uses a different database, the strategy has 
been to use xml schemes as templates for exchanging information between 
different databases.

Let me suggest this effort be broken down into:

a) malicious domain blocking
In this effort, people working in Paul's area will have much to offer.  
Frankly, the problem has become so large, it seems this should be done 
first, and then determine what else might be needed.

b) store-and-forward services
This effort should focus on the types of query and query results needed 
for defending store and forward servers that are structured to defend 
the reputation service.

c) relational services
This effort should focus on the types of query and query results needed 
for defending web servers that are structured to defend the reputation 
service.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Aug 2010 09:30:48 -0700

> Sent: Wednesday, August 11, 2010 1:27 AM
> To: SM
> Cc: [email-masked]; Murray S. Kucherawy

As I don't believe I saw anyone asserting that this work should be bound to any particular application, you appear to be arguing very hard for something that seems to me to already be a consensus view.

Let's spend our energy moving forward rather than doing battle to hit the same nail on the head repeatedly.

---

From: Tony Hansen <[email-masked]>
Date: Wed, 11 Aug 2010 17:43:37 -0400

I feel comfortable with the direction this is heading. However, I'd 
change the type specific queries to use something like

	dubious.example._web._rep.scorekeeper.example

	dubious.example._mail._rep.scorekeeper.example

for "type"-specific queries.

	Tony Hansen

---

From: "John R. Levine" <[email-masked]>
Date: 11 Aug 2010 19:31:42 -0400

> I feel comfortable with the direction this is heading. However, I'd change 
> the type specific queries to use something like
>

OK by me, although it'll be interesting to define the set of names.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Aug 2010 16:42:40 -0700

> Sent: Wednesday, August 11, 2010 4:32 PM
> To: Tony Hansen
> Cc: [email-masked]
> change

I think I agree.  Why not leave it to the reputation provider to do this, making it explicit (or general, by not using them) what the *ahem* domain of the reputation is, and save us an IANA consideration?

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Aug 2010 16:44:36 -0700

At 7:31 PM -0400 8/11/10, John R. Levine wrote:
>>I feel comfortable with the direction this is heading. However, I'd change the type specific queries to use something like
>>

Maybe consider all-digit "names": dubious.example._80._rep.scorekeeper.example ...

--Paul Hoffman, Director
--VPN Consortium

---

From: "John R. Levine" <[email-masked]>
Date: 11 Aug 2010 19:49:39 -0400

> Maybe consider all-digit "names": dubious.example._80._rep.scorekeeper.example ...

My intention using subdomains was so that you could have different 
opinions of, say, mail from a domain vs. web sites hosted at the domain. 
I don't understand what numbers would do other than be opaque.

R's,
John

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Aug 2010 17:06:44 -0700

At 7:49 PM -0400 8/11/10, John R. Levine wrote:
>My intention using subdomains was so that you could have different opinions of, say, mail from a domain vs. web sites hosted at the domain. I don't understand what numbers would do other than be opaque.

Sorry, I was being obscure. TCP ports instead of their names. 80 == HTTP, 25 == SMTP, and so on.

--Paul Hoffman, Director
--VPN Consortium

---

From: Douglas Otis <[email-masked]>
Date: Wed, 11 Aug 2010 17:12:00 -0700

>     dubious.example._mail._rep.scorekeeper.example
While we are selecting the color of the shed...

What problem will this service resolve for the web? For example, it is 
not apparent how will this can block an exploit on some user's web page 
without blocking the entire domain.

What problem will this service resolve for email?

Nearly all large providers emit a fair amount of malicious content due 
to the number of compromised accounts.  Bad actors also exchange benign 
content among their thousands of owned domains, and then one-by-one, 
after obtaining good ratings, launch blitzkrieg attacks.  Bot-nets 
normally win in a reactive Whack-a-Mole game, especially when they can 
also hold back your mallet by DDoSing the service.

How will this seemingly exposed service be defended against abuse?

The greatest difficulty ahead in taking the naive approach of "see what 
works" is that publishing ratings in DNS does not share the information 
needed to defend blocking decisions.  The imagined magic fully automated 
rating schemes full of secret sauce is not going to work in a world of 
bot-nets.  Once a domain has shown itself malicious, over time, the 
domain must remain blocked, otherwise this would allow the kriegspiel to 
continue unabated.  Supporting such a domain blocking effort will not be 
inexpensive either, for obvious reasons.

Solve the difficult problem first, the support of domain blocking 
decisions.  Do this before deciding on how to publish the results of the 
information.  Use of DNS Response Policy Zones will not require any 
other information to be published in DNS, provided the policy returns 
NXDOMAIN.  This approach also will not require any changes to be made in 
MTAs or web browsers.

-Doug

---

From: Paul Ferguson <[email-masked]>
Date: Wed, 11 Aug 2010 17:13:34 -0700

On Wed, Aug 11, 2010 at 5:06 PM, Paul Hoffman <[email-masked]>
wrote:

>>>
>>>Maybe consider all-digit "names":
>>>dubious.example._80._rep.scorekeeper.example ...
>>

Then I suppose you would also have to support wildcards for domains which
are 100% malicious, regardless of port?

- - ferg

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Aug 2010 01:21:06 +0100

> I don't understand what numbers would do other than be opaque.

So just to question the idea of domains for a moment. Are domains
the right/only things for which we'd like to enable folks to
query reputation? For example, what about specific email addresses?
Or perhaps more reasonably, since there are databases, WiFi BSSIDs?
(I would have used URIs as an example, but didn't since they
queries containing full URIs would have encoding issues that
would just be distracting for now.)

Put another way: why should the interesting part of the query
have to include a domain name that exists in the DNS?

S.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Aug 2010 17:38:39 -0700

>are 100% malicious, regardless of port?

Sure. Port 0 works fine for that (ignore the current registration in the IANA database; it is a mistake).

--Paul Hoffman, Director
--VPN Consortium

---

From: John Levine <[email-masked]>
Date: 12 Aug 2010 01:15:36 -0000

> I think I agree.  Why not leave it to the reputation provider to do
> this, making it explicit (or >general, by not using them) what the
> *ahem* domain of the reputation is, and save us an IANA
> consideration?

I think the point of _web and _mail was so that one could design
provisioning systems with a known set of buttons.  If it's
per-provider, better to make it part of the domain name to the right
of the _rep.

But this is a nit, we can worry about it whenever.

How about the model of the triplet of score,confidence,NAICS ?

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Aug 2010 02:23:56 +0100

> How about the model of the triplet of score,confidence,NAICS ?

Score and confidence are fine. The NAICS part is, I
have to assume, a joke.

S.

---

From: "John R. Levine" <[email-masked]>
Date: 11 Aug 2010 22:10:09 -0400

> Score and confidence are fine. The NAICS part is, I have to assume, a 
> joke.

My, aren't we provincial.

As I said, if you have a better suggestion for a set of widely used and 
freely available codes to identify types of organizations, I'd be happy to 
use something else.  But NAICS is what people use.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 11 Aug 2010 22:14:48 -0400

> have to include a domain name that exists in the DNS?

Mostly to keep the scope of the project finite.  (And, of course, it does 
say "domainrep" up there on the subject line.)

If people wanted to publish reputation for IP addresses, it'd be obvious 
enough how to adapt the rDNS encoding to do that.  I suppose you could 
encode other stuff, but once you get past domains and IPs, it appears to 
me that the utility rapidly drops off.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Aug 2010 21:48:41 -0700

> Behalf Of Paul Hoffman
> Sent: Wednesday, August 11, 2010 5:39 PM
> To: Paul Ferguson
> Cc: [email-masked]

You could query twice, once with the port-specific prefix and once without, I suppose.  (Or in the opposite order perhaps.)  This gets shortened if there's an understanding with the reputation provider that it does/doesn't do port-specific stuff.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Aug 2010 21:51:12 -0700

> Behalf Of Stephen Farrell
> Sent: Wednesday, August 11, 2010 6:24 PM
> To: John Levine
> Cc: [email-masked]

There has been some interest in the idea of conveying what kind of organization is, or appears to be, associated with a domain.  How that's determined is unspecified, but I guess that would be up to the reputation provider anyway.

If people really hate the idea of NAICS here, maybe the reputation provider is free to come up with its own set of names or codes that's used between it and its consumers, and we just have to create a syntax that works.

---

From: John Levine <[email-masked]>
Date: 12 Aug 2010 05:17:51 -0000

>If people really hate the idea of NAICS here, maybe the reputation
>provider is free to come up with its own set of names or codes that's
>used between it and its consumers, and we just have to create a
>syntax that works.

Ewww.  If I want to whitelist mail from banks, or blacklist mail from
mortgage brokers,, it sure would be nice to be able to configure in
categories 5221 and 52231 rather than having to try and figure out
what each provider's names for them are.

I think the only objection I've seen to NAICS seems to be that it's
published by the US government, not that the set of categories won't
do the job.  For anyone who's interested in this, I encourage you
to take a look at the categories and see if you think they're
reasonable, and if not, suggest something that would work better.

http://www.census.gov/cgi-bin/sssd/naics/naicsrch?chart=2007

R's,
John

PS: The ISO 3166 list on which ccTLDs are based was until recently
managed by DIN in Berlin.  Nonetheless, it is not my impression that
the DNS is secretly controlled by the Germans, and you know who I
mean.

---

From: Leif Johansson <[email-masked]>
Date: Thu, 12 Aug 2010 10:10:11 +0200

> Sure. Port 0 works fine for that (ignore the current registration in the IANA database; it is a mistake).

This seems to assume that the port is suitable as an endpoint
identifier. I'm not sure that is true (anymore). For instance
were I to build a reputation service for a set of SAML relying
parties the service endpoint would be a URI.

	Cheers Leif

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Aug 2010 09:31:08 +0100

> My, aren't we provincial.

Apparently you are:-)

> freely available codes to identify types of organizations, I'd be happy
> to use something else.  But NAICS is what people use.

People where? I think that were this an appropriate time to get
into that detail then the onus would be on you to show that this
could be acceptable outside of NA and that its coverage is
appropriate for the Internet and not just NA.

The issue for me is not mainly its origin, its that its
a scheme for industry (which doesn't cover everything that may
possess a reputation score), and I don't believe that all
worldwide industry is organised along north American lines.

I guess some folks might have an issue with change control
for the scheme residing with a national government, but that's
less of a concern for me.

In any case, this is all extremely premature. I think you
first need to say why an organisation classification value
is generally useful before its encoding becomes an issue.
Such a value may or may not be a good idea generally, I don't
know.

I can see why it'd be useful for mail and maybe web services
for some people but I guess that it'd lead to communications
being unncessarily blocked in some cases, at least my
experience with nanny web filters is that they all get this
wrong sometimes.

Secondly, this seems to represent a leakage of the secret
sauce from the server to the client - if organisation type
is sent back, then why not any other element of the secret
sauce? Seems like a slippery slope. Could be a good or a bad
slope to slide down though.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Aug 2010 10:52:57 +0100

On 12/08/10 03:14, John R. Levine wrote:
> Mostly to keep the scope of the project finite.  

Sure. We need to get there after we've explored it a bit.

> (And, of course, it
> does say "domainrep" up there on the subject line.)

Right. That is the central, but not necessarily the only,
idea.

> enough how to adapt the rDNS encoding to do that.  

Right. I would guess BSSIDs would be easy enough via an ENUM
like mechanism too.

> I suppose you could

What's not clear is whether that's because of limitations due to
wanting to encode everything into DNS or for some other reason.

S.

---

From: "John R. Levine" <[email-masked]>
Date: 12 Aug 2010 10:39:46 -0400

> is generally useful before its encoding becomes an issue.

Sigh.  As I think I've said at least three times now, some mail systems 
may want to handle incoming mail differently if they know it's from a 
particular kind of organization, with banks and governments being the 
usual examples.

This isn't hypothetical. When we were talking about this at DAC, people 
who handle rather a lot more mail than you or I do said this would be 
useful.

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Aug 2010 15:51:11 +0100

> particular kind of organization, with banks and governments being the

Yes, you have asserted that. But not said why its always or even
frequently relevant, i.e. what would I do with the information that
dance.example.com is probably an ok ballet company?

> who handle rather a lot more mail than you or I do said this would be

I don't doubt that. However, that doesn't mean that an industry
code of any sort is something that a generic Internet standard
for domain reputation should necessarily include as part of every
query response.

It could be that there are just a couple of interesting classes
of domain for which this is useful, and that the reputation
supplier might offer a different interface for querying those.
I don't know, but I'd hate to burden every client with having
to understand whatever classification system were to be used
and force every reputation vendor to classify all domains
accordingly.

S.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 Aug 2010 07:52:21 -0700

At 10:39 AM -0400 8/12/10, John R. Levine wrote:
>Sigh.  As I think I've said at least three times now, some mail systems may want to handle incoming mail differently if they know it's from a particular kind of organization, with banks and governments being the usual examples.
>
>This isn't hypothetical. When we were talking about this at DAC, people who handle rather a lot more mail than you or I do said this would be useful.

An example that was given was "if I'm in a grey area, I would drop mail from a tire manufacturer before I would drop mail from a bank or government".

Further, two of the reputation services said that they had customers who already bought this information from them. That makes it sound useful, even if you personally don't understand the reason why people would buy it.

--Paul Hoffman, Director
--VPN Consortium

---

From: "John R. Levine" <[email-masked]>
Date: 12 Aug 2010 11:03:06 -0400

> and force every reputation vendor to classify all domains

Hmmn.  Since I never said that a vendor would have to classify all 
domains, and explicitly said that a code zero would mean don't know, I 
have to conclude that whatever you're opposed to is something other than 
the proposal I made a few messages back.

So I don't see any further point in arguing here.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 12 Aug 2010 11:09:44 -0400

> who handle rather a lot more mail than you or I do said this would be

+1

This isn't just convenience either.  My research with scalar reputation values 
convinces me this data point would affect how I do the math for what's "OK" or 
"not OK".

Scott K

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 Aug 2010 08:09:37 -0700

>dance.example.com is probably an ok ballet company?

Why does it need to even be "frequently" relevant? Many HTTP headers are rarely relevant, but we don't prohibit them or even suggest that they not be used.

>for domain reputation should necessarily include as part of every

Correct. Fortunately, that is not what John's proposal says. (We are talking about his specific proposal, yes?)

>and force every reputation vendor to classify all domains

Fully agree. Fortunately, I didn't see that burden in the proposal. In fact, I would expect that most clients wouldn't understand *any* codes; they are only going to care about the rating.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Aug 2010 16:24:27 +0100

> Correct. Fortunately, that is not what John's proposal says. (We are talking about his specific proposal, yes?)

Yes. I didn't see where that was optional to include. If I
missed that, sorry. (And "Don't know" is different from
missing I think.)

> Fully agree. Fortunately, I didn't see that burden in the proposal. In fact, I would expect that most clients wouldn't understand *any* codes; they are only going to care about the rating.

If understanding the code is optional for clients, and
unsupported by most, then why would it always be present?

I can also imagine client implementers seeing this as an
unnecessary burden unless its very very obviously optional.
People will complain in cases where the response contains
a code for something that the client doesn't grok even
for those clients that do understand one or two codes.
So make it part of some kind of extensibility thing maybe,
then whatever the Italian equivalent for NAICS is could
be used where its useful.

Aside from that, I'm still not ok with the idea that we
pretend that an industry code like NAICS is relevant for
all domains, which is how I read his proposal.

S.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 12 Aug 2010 10:13:20 -0700

> Sent: Thursday, August 12, 2010 8:24 AM
> To: Paul Hoffman
> Cc: John R. Levine; [email-masked]
> [...]

So is the solution here to make the two integers expressing reputation and confidence mandatory, and the third (or any number of additional ones) optional?  For example:

	Reply = "r=" 1*DIGIT CFWS "c=" 1*DIGIT *( CFWS tag "=" 1*DIGIT )

...where the other "tag"s get registered with their own semantics, or are defined by the reputation provider and out of scope for the protocol specification itself.  Then if the provider wants to provide a "naics=" field, it can, and the clients can either use it or ignore it, and someone else can provide its own encoding mechanism, etc.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 12 Aug 2010 10:29:09 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Thursday, August 12, 2010 1:31 AM
> To: John R. Levine
> Cc: [email-masked]

I'm not sure I understand this objection, but maybe you touched on it below: Is the fact that "NA" is in the name the objectionable part of this -- were I to take the entire data set and call it MFBC (Murray's Fun Business Codes), would that make people feel better? -- or is there something about the way the data are actually organized that makes it the wrong approach?

> less of a concern for me.

That was part of why I posed the "IANA" question earlier.  At least then it's not governmental or perceived as US-centric, although it creates more work for IANA and sets a medium-height bar for adding to or otherwise amending the list, plus implementers will need a way to stay abreast of changes.

As for secret sauce leakage, maybe that's a good argument for making it optional; if the algorithm treats all domains equally then exposure of differentiating information might be seen as useful, while if the type of organization being reported is rolled into the reputation score itself, this becomes unnecessary.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 12 Aug 2010 10:33:01 -0700

On 8/11/10 7:14 PM, John R. Levine wrote:
> Mostly to keep the scope of the project finite.  (And, of course, it 
> If people wanted to publish reputation for IP addresses, it'd be 
> obvious enough how to adapt the rDNS encoding to do that.  I suppose 
> you could encode other stuff, but once you get past domains and IPs, 
> it appears to me that the utility rapidly drops off.
John,

If domain reputation is intended to support web reputation, as your 
breakdown suggests, then the path component also needs to be part of the 
query.  Clearly such information should be encoded and not directly 
exchanged.  For an example of how that might be done, see smart browsing.

If domain reputation is intended to support email reputations, which 
appears to be the true intent, then there are other aspects that we have 
included in the past in our reputation services and appear to have 
become once again relevant.  There are many ways third-party services 
can be offered.

Some of these services do not:
  a) confirm the address of a subscriber
  b) authenticate the sender
  c) include Authentication-Results headers
  d) remove deceptive Authentication-Results headers
  e) include list-id header fields in their mailing-lists
  f) post process email for valid recipients

Flags indicating the nature of a domain's traffic:
   1) malware or phishing
   2) bulk
   3) transactional
   4) financial
   5) merchant
   6) business
   7) informational
   8) amusement
   9) advertisement
10) notification
11) phished
12) political
13) racial
14) sexual
15) gambling
16) language x, y, z
17) country x, y, z

Decisions will be based upon general categories.  A scheme that breaks 
business types into a fine granularity, will then need to be recombined 
back into general categories before a decision can be made.  It seems 
illogical to impose the added burdens this would entail upon both the 
service provider and the consumer.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 12 Aug 2010 14:26:30 +0200

> I didn't see anyone trying to constrain any of this activity specifically to email or anti-spam.

Doug and I have been doing so.  It's because email users can perpetrate abuse 
under a /domain/ name.  Clients of other protocols can often be identified 
only by IP number --unless they logged in using an email address...

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 12 Aug 2010 11:34:45 -0700

> Behalf Of Alessandro Vesely
> Sent: Thursday, August 12, 2010 5:27 AM
> To: [email-masked]

Well, then I disagree.  There's certainly use in evaluating a domain name found in a URL within an email, for example.

A validated DKIM domain is but one of myriad possible questions that it would be useful to ask of a reputation system.  I don't think we should try to constrain this work in that way.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Aug 2010 19:59:13 +0100

> ...where the other "tag"s get registered with their own semantics, or are defined by the reputation provider and out of scope for the protocol specification itself.  Then if the provider wants to p…

Right, that'd work. I assume there'd be a need to be an IANA
registry for "naics=" and its ilk.

S.

> 
> _______________________________________________
> domainrep mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/domainrep
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Aug 2010 20:15:16 +0100

> I'm not sure I understand this objection, but maybe you touched on it below: Is the fact that "NA" is in the name the objectionable part of this -- were I to take the entire data set and call it MF…

No. I'd have the same problem with an Irish industry code. I'm
apparently not getting this over, so I'll give it one more
try. (But with an optional code, its much less of an issue,
so no need to keep this going.)

I have at least three problems with the NAICS suggestion:

- Its a regional classification designed for other (statistical)
  purposes. I very much doubt that any such regional
  classification will map to the entire Internet. For example,
  I wouldn't be surprised if an EU financial regulator objected
  to some US reputation vendor assigning an EU regional code
  that means that a domain is part of a financial institution,
  I'm willing to bet a beer that some such problem would
  arise somewhere.

- 2nd problem is also regional-related: one cannot expect
  client implementers and reputation service providers
  from outside whatever region produced the scheme to apply
  it correctly or easily. The NAICS site says that you can
  pay someone to give you lists of the NAICS codes for
  businesses. I very much doubt any of the companies who
  sell that are solely based in New Zealand and I suspect
  that any NZ reputation supplier would be disadvantaged
  by that and more likely to err. The same issue would
  arise with any regional code that aimed to cover the
  entire Internet.

- Its an industrial code. Not all domains are related to
  industry, and so therefore cannot be classified, so
  its clearly unsuitable on that basis alone, except for
  a subset of domains.

Anyway, as an optional thing, its just fine if folks want
to do that, so long as we all aren't expected to do it.

S.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 12 Aug 2010 13:23:58 -0700

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

I guess the use of "regional" in this debate is what baffles me.  That integer X means "bank" doesn't seem to me to have a regional component, other than who assigned it.  If that's not the issue, I guess then the concern is that what qualifies as "bank" in one region might be different than in another.  Is that it?

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 12 Aug 2010 16:27:53 -0400

On Thu, Aug 12, 2010 at 01:23:58PM -0700, Murray S. Kucherawy wrote:

> I guess then the concern is that what qualifies as "bank" in one
> region might be different than in another.  Is that it?

It would seem that an early question any taxonomy is going to run
into is, "Who decides?"

A

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 12 Aug 2010 13:31:29 -0700

> Behalf Of Andrew Sullivan
> Sent: Thursday, August 12, 2010 1:28 PM
> To: [email-masked]

For that matter, why does everyone think ASCII is okay?  Isn't the "A" part objectionable?

I'd be perfectly fine with any table matching integers to business types, no matter who comes up with it.  I guess that's why I don't get the objection.  There must be something about that particular data set that I just don't get yet.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Aug 2010 21:54:28 +0100

> I guess the use of "regional" in this debate is what baffles me.  That integer X means "bank" doesn't seem to me to have a regional component, other than who assigned it.  If that's not the issue,…

Right, that's an example. There are literally 10's of
thousands of Swiss savings banks (or were, when I did
a bit of work related to that a decade ago), some with
only one or two employees, then there are microfinance
outfits in developing regions, credit unions, some of
which are for particular city districts, and some that
are part of larger industrial enterprises with nothing
to do with banking (in Ireland), there's the Swedish
farmer's union that has (or had) its own a bank, etc
etc. so even in one of the most regulated areas things
vary a lot once you get outside a particular region.
Are you telling me that NAICS has relevant codes for
all of those? How would you know?

Or try football, that's three totally different sports
in the US, UK and Ireland:-)

How about medical? I've no idea how that might work
in China for example (and hope not to find out when
we go there:-)

Point is, if all you care about is if the reputation
service says its a bank then there's no need to
inherit any of that complexity. If there are only
a small set of domain types that might be useful
then just start an IANA registry. (However, before
using that value, a reputation provider might want
to check with their local financial regulator if
they're allowed make such statements, I dunno.)

But once more: I'm ok as long as its really optional.

S.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 12 Aug 2010 14:31:53 -0700

On 8/12/10 11:34 AM, Murray S. Kucherawy wrote:
> > On Thursday, August 12, 2010 5:27 AM Alessandro Vesely wrote:
> >>> From: Paul Ferguson [mailto:[email-masked]] Stop
> >>> thinking about spam. Please.
> > Doug and I have been doing so.  It's because email users can
> > perpetrate abuse under a /domain/ name.  Clients of other protocols
> > can often be identified only by IP number --unless they logged in
> > using an email address...
>
>  Well, then I disagree.  There's certainly use in evaluating a domain
>  name found in a URL within an email, for example.

In order to evaluate a URI found within an email, more than just the 
domain MUST be included.  Often shortened URLs require the path to 
evaluate the actual source.

>  A validated DKIM domain is but one of myriad possible questions that
>  it would be useful to ask of a reputation system.  I don't think we
>  should try to constrain this work in that way.

Unless such a system is allowed to cover more than just a domain, the 
utility of the service is significantly limited to perhaps:

a) the complete blocking of a malicious domain

b) authenticated domains of email addresses

c) authenticated domains of host names

Due to the fact that email does not require any domain to have been 
authenticated, some will want to base reputation on domains authorizing 
the actions of a host by its IP address.  An authorization by IP address 
model for domain reputation would be extremely difficult to support, 
since there would not be any direct evidence of a domain having 
originated objectionable content.

Without a way to determine whether an assumption is in error, errors 
might result in a domain being blocked without recourse.  It is common 
to find providers authorized by thousands of domains.  However, many 
providers do not correlate message elements that could be used as 
authorization with that of a particular sender.  In addition, 
authorization might be based upon the return-path or upon the purported 
responsible address, where the intended address might not have been 
examined.

Often authorization proponents disregard the lack of authentication, and 
insist that domains injured by any error must find different providers.  
Unfortunately, using a different provider will not resolve the problem 
created by erroneous reputations assigned to their domain.

Its like a neighborhood park asking parents to authorize unaccompanied 
children they wish allowed in the facility.  Guards at the park don't 
confirm the child's name, but accept the name given whenever it matches 
an authorization.  Now imagine the park has decided to hold parents 
liable for actions of their authorized child, without anyone really 
knowing whether the child gave their true name when being admitted.

To reliably accept email from sources within IPv6, a cryptographic 
method confirming the issuing host would be beneficial, since these IP 
addresses will prove problematic for establishing a source identity.  If 
such a requirement for authenticating the issuing host was established 
for email, this would better ensure domains are not injured through 
incorrect source assumptions when establishing domain reputation.

-Doug

---

From: John Levine <[email-masked]>
Date: 12 Aug 2010 21:41:28 -0000

>Right, that's an example. There are literally 10's of thousands of
>Swiss savings banks (or were, when I did a bit of work related to
>that a decade ago), some with only one or two employees, then there
>are microfinance outfits in developing regions, credit unions, some
>of which are for particular city districts, and some that are part of
>larger industrial enterprises with nothing to do with banking (in
>Ireland), there's the Swedish farmer's union that has (or had) its
>own a bank, etc etc. so even in one of the most regulated areas
>things vary a lot once you get outside a particular region.  Are you
>telling me that NAICS has relevant codes for all of those? How would
>you know?

Yeah.  They're banks.  Code 5221.  What sort of maniac would waste
time trying to invent separate reputation categories for all of them?

We also have rather a lot of types of banks here in North America*,
and NAICS does not have a hundred separate subcategories because
there's no point.

R's,
John

* - Utah industrial banks, and the Alberta Treasury Branches, for example

---

From: Douglas Otis <[email-masked]>
Date: Thu, 12 Aug 2010 15:36:16 -0700

> and NAICS does not have a hundred separate subcategories because
NAICS has 19746 items combined into different categories.  I can imagine 
having a category representing "public safety" which then might include 
NOAA, and its equivalent for different regions, and things like fire, 
ambulance, police, but these are spread out into different categories. 
This list also includes 812990 balloon-o-gram services, and 16342 
Facsimile machine rental or leasing, but nothing directly for an email 
provider, and its many subcategories.

Internally we have our own set of categories that are flagged as bits 
within a large large integer. Categorization should relate to the 
protocol evaluated.  NAICS appears to represent a fairly poor fit for 
most Internet related protocols.  Many of these categories seem related 
to different tax revenue sources based on fairly old regulations.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 13 Aug 2010 12:47:10 +0200

>     http://unstats.un.org/unsd/cr/registry/isic-4.asp

FWIW, there is an European classification

http://epp.eurostat.ec.europa.eu/portal/page/portal/nace_rev2/introduction

Possibly, the right syntax is "code=X, code-type=NAICS", rather than naics=X. 
  IMHO, such info should be provided by the registrar in the relevant WHOIS 
field.  Is caching/complementing WHOIS an integral part of a domain 
reputation system?

Rather than (or in addition to) detailed industrial classification, I think 
it is relevant to answer Internet-specific questions, such as who are the 
domain's users, how they subscribe, and the like.

---

From: Nathaniel Borenstein <[email-masked]>
Date: Fri, 13 Aug 2010 07:21:40 -0400

On Aug 12, 2010, at 6:36 PM, Douglas Otis wrote:

> NAICS has 19746 items combined into different categories

I worry more about the 19746 than the NA.

How many of these categories are there?  I think we need a human-scale number (1 or 2 digits) if we're going to be able to develop software that can discriminate meaningful based on such distinctions among institutions.  A small number of categories (financial/medical/retail/educational/etc., or text/image/video/audio/message/multipart/application) is often more manageable than a large one.   I think it should be as small as possible (but no smaller).  -- nsb

---

From: Douglas Otis <[email-masked]>
Date: Fri, 13 Aug 2010 10:19:58 -0700

> How many of these categories are there?  I think we need a human-scale number (1 or 2 digits) if we're going to be able to develop software that can discriminate meaningful based on such distinctio…
Might I also suggest the nature of traffic from a domain could fit into 
several categories.  The way we handle this situation is to set bits 
within integers to flag each applicable category.  In this way, a small 
response is able to contain a significant amount of actionable data.

One then wonders how this might evolve.  What about content not suitable 
for minors?  Would such a category place a duty on the service to 
indicate such possible status?

I agree with a small set of categories, which is what we use 
internally.  Keeping it even simpler, such as sticking to categories 
declared in the IODEF format for example, could keep reporting from 
becoming a nanny service, which is something we also offer, but I doubt 
the IETF would endorse such... ugliness.

When reputation is about email, it would be helpful to know whether they 
also offer third-party services that damage DKIM signatures.  If they 
properly implement Authentication-Results headers.  Whether the system 
publicly issuing their messages can be authenticated, and by using which 
method... etc.

-Doug

---

From: John Levine <[email-masked]>
Date: 13 Aug 2010 17:22:12 -0000

>> NAICS has 19746 items combined into different categories ...

>I think it should be as small as possible (but no smaller).  -- nsb

As I think I said in an earlier message, NAICS codes are like Dewey
Decimal numbers, more digits give you finer distinctions.  If you look
here:

You'll see that there are about 25 two-digit areas, which are then
broken down into finer areas.  So, for example, 52 is Finance and
Insurance, 522 is Credit Intermediaries and Related Activities, 5221
is Banks, 5222 is non-bank lenders, and 5223 is Activities Related to
Credit Intermediation such as mortgage brokers.

My expectation is that reputation services would publish as many
digits as they know, and consumers would use as many digits as they
find useful.  So if you're treating all bank-like things the same,
anything that starts with 522 is a bank.  On the other hand, if you
find mortgage brokers to be sleazier than banks, you might do
something different with 5223.

The UN's ISIC, and EU's NACE, which appears to be a mutant version of
ISIC, work roughly the same way: 01 is farming, 01.4 is animal
farming, 01.44 is camels and llamas, and 01.46 is swine.

R's,
John

---

From: John Levine <[email-masked]>
Date: 13 Aug 2010 18:06:12 -0000

>Possibly, the right syntax is "code=X, code-type=NAICS", rather than naics=X. 

I would really rather have one set of codes, no matter what they are.
The goal for me at least is to have a simple way of asserting things
like "this is a bank".  If there's an unlimited set of unknown code
points, checking the code has now turned from a simple string match
into a remote database lookup.

>  IMHO, such info should be provided by the registrar in the relevant WHOIS 

No.  Why would you assume that all subdomains under the same WHOIS
entry would be the same type of organization? 

Look, for example at HP.COM which I would categorize as a manufacturer
of electronic equipment or something like that, whereas
SHOPPING.HP.COM is a mail order vendor of office supplies.

For that matter, why would you assume that all domains have WHOIS info
in the first place?

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 13 Aug 2010 14:11:00 -0400

> into a remote database lookup.

I have to agree with this.  If we have flexible code types, then we
have to have some kind of negotiation for which code type to use
(suppose you're introducing a new code type; you'd want to support
both code types during the transition).  I agree it'd be more
flexible, but I think it would be at the cost of complexity that
doesn't have a compelling need.

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 13 Aug 2010 11:20:11 -0700

John,

The two digit information is of little use, but even when attempting to 
find meaningful categories that might relate to email, it only becomes 
more confusing. For example would it be 518210, or 541860. Would a 
company distributing refrigerator magnets be in the same category as a 
bulk email distributor?

These categories are more related to taxes than something that would 
involve the Internet. These lists are simply not useful, nor is this 
number scheme suitable for aggregation.

Why would it be important to categorize the specific type of business?

A general categories such as financial transactions would cover a large 
range of services that are likely being phished.

However, knowing a domain is prone to being phished might represent a 
category on its own.

,---
11 Agriculture, Forestry, Fishing and Hunting
21 Mining, Quarrying, and Oil and Gas Extraction
22 Utilities
23 Construction
31 - 33 Manufacturing
42 Wholesale Trade
44-45 Retail Trade
48-49 Transportation and Warehousing
51 Information
52 Finance and Insurance
53 Real Estate and Rental and Leasing
54 Professional, Scientific, and Technical Services
55 Management of Companies and Enterprises
56 Administrative and Support and Waste Management and Remediation Services
61 Educational Services
62 Health Care and Social Assistance
71 Arts, Entertainment, and Recreation
72 Accommodation and Food Services
81 Other Services (except Public Administration)
92 Public Administration

----
517 Telecommunications

Industries in the Telecommunications subsector group establishments that 
provide telecommunications and the services related to that activity 
(e.g., telephony, including Voice over Internet Protocol (VoIP); cable 
and satellite television distribution services; Internet access; 
telecommunications reselling services). The Telecommunications subsector 
is primarily engaged in operating, and/or providing access to facilities 
for the transmission of voice, data, text, sound, and video. 
Transmission facilities may be based on a single technology or a 
combination of technologies. Establishments in the Telecommunications 
subsector are grouped into four industry groups. The first three are 
comprised of establishments that operate transmission facilities and 
infrastructure that they own and/or lease, and provide 
telecommunications services using those facilities. The distinction 
among the first three industry groups is the type of infrastructure 
operated (i.e., wired, wireless, or satellite). The fourth industry 
group is comprised of establishments that provide support activities, 
telecommunications reselling services, or many of the same services 
provided by establishments in the first three industry groups, but do 
not operate as telecommunications carriers.
Establishments primarily engaged as independent contractors in the 
installation and maintenance of broadcasting and telecommunications 
systems are classified in Sector 23, Construction. Establishments known 
as Internet cafes, primarily engaged in offering limited Internet 
connectivity in combination with other services such as facsimile 
services, training, rental of on-site personal computers, game rooms, or 
food services are classified in Subsector 561, Administrative and 
Support Services, or Subsector 722, Food Services and Drinking Places, 
depending on the primary activity.

518210 Data Processing, Hosting, and Related Services

This industry comprises establishments primarily engaged in providing 
infrastructure for hosting or data processing services. These 
establishments may provide specialized hosting activities, such as web 
hosting, streaming services or application hosting, provide application 
service provisioning, or may provide general time-share mainframe 
facilities to clients. Data processing establishments provide complete 
processing and specialized reports from data supplied by clients or 
provide automated data processing and data entry services.
Illustrative Examples:

Application hosting Application service providers Computer input 
preparation services Computer time rental
Microfilm imaging services Optical scanning services Web hosting
Cross-References. Establishments primarily engaged in--
• Providing text processing and related document preparation 
activities--are classified
in Industry 561410, Document Preparation Services;
• Providing on-site management and operation of a clients’ 
data-processing facilities-- are classified in U.S. Industry 541513, 
Computer Facilities Management Services;
• Providing Internet access services in combination with web 
hosting--are classified in U.S. Industry 518111, Internet Service Providers;
• Operating web search portals--are classified in U.S. Industry 518112, 
Web Search Portals;
• Providing access to computers and office equipment, as well as other 
office support services--are classified in Industry 56143, Business 
Service Centers;
• Processing financial transactions, such as credit card 
transactions--are classified in Industry 522320, Financial Transactions 
Processing, Reserve, and Clearinghouse Activities; and
• Providing payroll processing services--are classified in U.S. Industry 
541214, Payroll Services.

541860 Direct Mail Advertising

This industry comprises establishments primarily engaged in (1) creating 
and designing advertising campaigns for the purpose of distributing 
advertising materials (e.g., coupons, flyers, samples) or specialties 
(e.g., key chains, magnets, pens with customized messages imprinted) by 
mail or other direct distribution; and/or (2) preparing advertising 
materials or specialties for mailing or other direct distribution. These 
establishments may also compile, maintain, sell, and rent mailing lists.
'---

-Doug

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 13 Aug 2010 11:47:32 -0700

> For that matter, why would you assume that all domains have WHOIS info

...or that the information already there is correct? The domain WHOIS is
already heavily polluted with incorrect or outdated data.

- - ferg

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 13 Aug 2010 12:45:43 -0700

> This isn't hypothetical. When we were talking about this at DAC, people who handle rather a lot more mail than you or I do said this would be useful.

For large-scale filtering operators & truly creative mail UI developers, accurately categorizing mail is the holy grail AFTER the holy grail of getting all the spam out of the way.

Which categories are interesting can vary depending on who you're talking to and who they've talked to recently and how much caffeine they've had, which I believe is why DAC chose such a broad list of categories.

---

From: SM <[email-masked]>
Date: Fri, 13 Aug 2010 13:11:38 -0700

Hi Murray,
>For that matter, why does everyone think ASCII is okay?  Isn't the 

ASCII is not okay.  Some people prefer XML. :-)

>I'd be perfectly fine with any table matching integers to business 
>types, no matter who comes up with it.  I guess that's why I don't 
>get the objection.  There must be something about that particular 
>data set that I just don't get yet.

You could use the European NACE classification or the International 
Standard Industrial Classification of All Economic Activities (ISIC).

Regards,
-sm

---

From: Nathaniel Borenstein <[email-masked]>
Date: Sun, 15 Aug 2010 11:42:05 -0400

On Aug 13, 2010, at 1:22 PM, John Levine wrote:

> Decimal numbers, more digits give you finer distinctions...

I'm sorry, I missed that.  The possibility of using more digits for more specificity is very appealing, best of both worlds.

I don't really have any remaining objection to NAICS, though I sympathize with those bothered by the "NA."   We could give it a new name, though, that wouldn't be a first.  

However, I'm concerned about the evolution of our *use* of any such taxonomy.  Anything like NAICS will have a change process and other needs that might not suffice for an Internet protocol.   (Searching the codes for "software" doesn't give me an appropriate classification for a cloud/SOA/old-AOL/Tymshare type of company.  That level of detail could be important when we start to worry about the reputations of reputation authorities.  And we will.)

One approach would be to start with NAICS-or-equivalent, but to give ourselves a lightweight hook to fork/augment its evolution, perhaps with an IETF registry or two, if it proves necessary.  -- Nathaniel

---

From: "John R. Levine" <[email-masked]>
Date: 15 Aug 2010 13:09:34 -0400

> However, I'm concerned about the evolution of our *use* of any such taxonomy.  Anything like NAICS will have a change process and other needs that might not suffice for an Internet protocol.   (Sea…

They do change it from time to time.  The current NAICS is 2007, previous 
one was 2002.  They don't unpublish the older versions and lots of people 
still use SIC, its 1990s predecessor.

I sympathize with concerns that the categories don't match what we're 
likely to use them for.  I think NAICS is a little closer than ISIC (which 
has seprate codes for goat and camel farms, but divides data processing 
into "web portals" and everything else) but neither is perfect.

Nonetheless, it seems very unlikely that this particular group, with 
little expertise in industrial taxonomy, could come up with a set of 
categories that worked better than ISIC or NAICS so as I've said, I'd pick 
one and use it, at least for straw man purposes.

R's,
John

---

From: Nathaniel Borenstein <[email-masked]>
Date: Mon, 16 Aug 2010 06:06:17 -0400

On Aug 15, 2010, at 1:09 PM, John R. Levine wrote:

> Nonetheless, it seems very unlikely that this particular group, with little expertise in industrial taxonomy, could come up with a set of categories that worked better than ISIC or NAICS so as I've said, I'd pick one and use it, at least for straw man purposes.

I agree completely, I just think it might be worth having a way for us to augment it with distinctions we don't want to wait 5 years for, such as discriminating between email marketers, cloud service providers, email security vendors, etc.   We may not want to wait for a twice-a-decade revision to give us those categories.  In fact, NAICS may never make those distinctions, so specific are they to our needs, which is why it might best be viewed as an IETF extension to NAICS.  -- Nathaniel

---

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

On 16/08/10 11:06, Nathaniel Borenstein wrote:
> I agree completely, 

I don't :-)

I just think it might be worth having a way for us to augment it with
distinctions we don't want to wait 5 years for, such as discriminating
between email marketers, cloud service providers, email security
vendors, etc.   We may not want to wait for a twice-a-decade revision to
give us those categories.  In fact, NAICS may never make those
distinctions, so specific are they to our needs, which is why it might
best be viewed as an IETF extension to NAICS.  -- Nathaniel

I think Murray's suggestion (make NAICS some kind of tagged option)
caters for this. If folks play with NAICS but then need something
else then they can do that. Personally, I don't think these industrial
classifications will useful for very long, but I guess so long as
we can change, there's no harm in trying.

S.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 16 Aug 2010 13:26:09 +0200

Stephen Farrell wrote:
>>> Nonetheless, it seems very unlikely that this particular 
>>> group, with little expertise in industrial taxonomy, could
>>> come up with a set of categories that worked better than ISIC
>>> or NAICS so as I've said, I'd pick one and use it, at least 
>>> for straw man purposes.
>>
>> I agree completely,
>
> I don't :-)

I'd agree on using it for straw man purposes _only_.  BTW, this 
would imply not using the term "NAICS" at all, and thus clears the 
NA objection too.

>> vendors, etc.

Doug has exemplified the inadequacy of NAICS very clearly.  See 
http://www.ietf.org/mail-archive/web/domainrep/current/msg00147.html

> we can change, there's no harm in trying.

A possible harm is inertia.  One thing that this particular group 
could do to preempt it is to define an initial set of one-digit 
classes and an easy procedure for augmenting it.

The initial classification should be very simple and obvious.  For 
example,

   "O" open, Internet-oriented domains.  They give web (wiki or blog)
       or email (mailboxes) access to unidentified, possibly
       duplicated users.

   "C" closed organizations.  They grant mailboxes or web access
       only to employees, affiliates, or other well-identified
       entities.  Their technical staff may contact users for
       security issues.

As for the augmenting procedure, it has to take into account the 
very classification process.  Who will assign such code to domains, 
and based on what sort of evidence or criteria?

Note that NAICS or similar classifications may well be mentioned in 
the augmenting procedure.  We could import whole branches, as 
needed, from whatever classification.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 16 Aug 2010 17:52:56 -0400

On Mon, Aug 16, 2010 at 01:26:09PM +0200, Alessandro Vesely wrote:
> A possible harm is inertia.  One thing that this particular group could 
> do to preempt it is to define an initial set of one-digit classes and an 
> easy procedure for augmenting it.

I can't quite tell whether you're proposing that we start with
something we're going to build, but make one taxonomy; or whether
you're suggesting we standardize a procedure for augmenting a base set
of classes.  The thing that worries me about the latter suggestion is
that we'll end up with classification schemes that are local only:
everyone will have their pet classes.  Since we're supposed to be
about interoperability at the IETF, it seems to me that it would be
better to have some proposal that converges on a single taxonomy.  

In any case, given that the IETF doesn't attract taxonomic expertise
the way other SDOs do, it seems to me it would be better to adopt some
external classification as the basis for work than to go off and make
our own.  I'm particularly concerned with suggestions like this:

> The initial classification should be very simple and obvious.

Obvious to one person is obscure to another.  The example you gave was
to me much less compelling than some other classes with which I'd
naturally divide up the universe, and I think we could spend a long
time arguing about which "obvious" classification was the one true
one.

A

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

---

From: John Levine <[email-masked]>
Date: 16 Aug 2010 23:16:07 -0000

>> The initial classification should be very simple and obvious.

At DAC, when we were working on VBR, at one point we had a detailed
taxonomy of mail types, based on the extensive experience of everyone
involved, and we ended up throwing everything out other than mailing
list, because it wasn't clear to anyone that the taxonomy solved any
problems.

I'm pretty sure that a reputation system that told me whether a sender
was a bank or a government would be useful.  I'm pretty sure that the
distinction between a camel farmer and a pig farmer is not.  Between
that I'm not sure.  This tells me that we need a place holder, and we
can worry about the details when we have more experience and more
comments from people who run real mail systems.

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Aug 2010 00:19:57 +0100

> comments from people who run real mail systems.

I do agree with that, esp. the "not sure" part.

However, I'd s/mail systems/mail and other systems/ if we conclude
this is about more than mail. (And I guess sender would be
replaced with something else as well for non-mail apps.)

S.

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 16 Aug 2010 16:29:53 -0700

Speaking as co-chair, for whatever weight that may carry on a pre-WG mailing list....

> we can change, there's no harm in trying.

It's hard to argue against the need for standard classifications, and even harder to argue against the need to change or update those classifications as our needs evolve.

But as we've already seen on this list, different people have very different criteria for differentiation of mail streams.  We could very easily end up arguing about definitions for decades without ever reaching a single taxonomy that'll work for everyone.

So I'd like to expand from Murray's original suggestion, and ask if we could please agree that:

1. the ability to reference a standard taxonomy of sender types is worthy of further discussion, and
2. the specific contents of said taxonomy are out of scope for this group.

If there's a strong desire for an IETF effort to create such a taxonomy, perhaps a separate (but obviously complimentary) effort could be spun up.  However, I don't think the domainrep effort has to wait for it.

Any strong opposition?  Does this need a formal call for consensus?

---

From: Douglas Otis <[email-masked]>
Date: Mon, 16 Aug 2010 16:52:23 -0700

> time arguing about which "obvious" classification was the one true
Andrew,

The concern is understandable, and there are proprietary products 
placing domains into specific categories. The overall number of 
categories normally does not exceed an ability to list "all that apply" 
as bit flags within a small data block.  Depending upon the protocol 
involved, these bit definitions change.

For email, some customers base acceptance upon the geo-location of the 
source.  Some base this on associated AS values deduced through 
resolution of servers. Some increase filtering thresholds when the 
domain is being spoofed, which often occurs with online financial 
related transactions.  One might imagine wanting recognition of 
government related sources, but access to these domains normally are 
controlled and are already distinct.

There are likely a number of third-party service categories that should 
be handled differently, type of authentications used, languages, 
etcetera, that will improve email's integrity when categorized.  
Acceptance based upon categories of businesses that some might view 
negatively, but that have little bearing upon behavior or importance, 
would only further Balkanize email.

Categorization for its own sake should be discouraged.  "It might be 
nice to know" does not offer suitable justification in the creation and 
support of a standardized category, especially when attempting to offer 
as much actionable information as possible within a single frame.  
Categories should not be offered that might otherwise obscure a domain's 
merits.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Aug 2010 01:08:01 +0100

> So I'd like to expand from Murray's original suggestion, and ask if we could please agree that:

Almost. My quibbles below. :-)

> 1. the ability to reference a standard taxonomy of sender types is worthy of further discussion, and

s/sender types/foo/ where foo are the things about which reputation
is asserted (domains, addresses, BSSIDs, whatever we end up with
there, maybe including mail senders,/authors/..., but equally maybe
just domains).

and s/a standard taxonomy/one or more standard taxonomies/

> 2. the specific contents of said taxonomy are out of scope for this group.

I think maybe the management of other taxonomies is almost always
out of scope, (other than to react to someone else's change control),
but any taxonomy that'd be useful needs to be encoded/tagged, which
latter part would have to be in scope.

The "almost always" above, is because it could be that there is some
Internet specific taxonomy that would end up in scope (e.g. "talks
RFCxxxx" if that were useful). But I'm not making any suggestions
there now, 'cause I've not got (or heard) any good ideas:-)

S.

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 17 Aug 2010 10:24:52 -0400

> comments from people who run real mail systems.

Could it be simplified for all use cases (meaning email and other
protocols) to simply say "high value" and "low value"?

-- 
Jeff Macdonald
Ayer, MA

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 17 Aug 2010 10:57:50 -0400

On Mon, Aug 16, 2010 at 04:52:23PM -0700, Douglas Otis wrote:
> placing domains into specific categories.

[other examples elided]

I can't tell if you're arguing that local evaluation is necessary, and
that therefore a single taxonomy won't work; or if you're arguing
instead along with me that balkanizing the categorization would be
bad.  Which were you intending?

> support of a standardized category,

I don't think anyone was arguing that way.  I think the argument was
instead that (1) there appears to be a need for categories; (2) we
don't have taxonometric expertise just clamouring to help out here;
(3) there are existing taxonomies to be employed.  If you are arguing
that (1) is false, then I don't understand the argument yet.

A

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

---

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

>protocols) to simply say "high value" and "low value"?

No, it's orthogonal.  I want to be able to publish reputation scores
that say, in effect, "this is spam, but it really is from Bank of
America."

A few months ago I got some mortgage spam to an address that only
appears on spam lists, with a valid BofA DKIM signature.  I treat that
differently from mail that purports to be from BofA but is actually a
phish.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 17 Aug 2010 14:09:07 -0400

On Mon, Aug 16, 2010 at 04:29:53PM -0700, J.D. Falk wrote:
> 2. the specific contents of said taxonomy are out of scope for this group.

I can support that.

A

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

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 17 Aug 2010 15:20:56 -0400

On Tue, Aug 17, 2010 at 1:18 PM, John Levine <[email-masked]> wrote:
> No, it's orthogonal.

But is it really?

> I want to be able to publish reputation scores

yes, I understand that. But you could also say "this is spam, but it
is from a high value domain."

-- 
Jeff Macdonald
Ayer, MA

---

From: Douglas Otis <[email-masked]>
Date: Tue, 17 Aug 2010 12:26:58 -0700

On 8/17/10 7:57 AM, Andrew Sullivan wrote:
>  I can't tell if you're arguing that local evaluation is necessary,
>  and that therefore a single taxonomy won't work; or if you're
>  arguing instead along with me that balkanizing the categorization
>  would be bad.  Which were you intending?

Indicating all possible categories of traffic emitted by a domain could 
prove beneficial.  Using 6 decimal digits to indicate a category makes 
it impractical to identify all relevant categories within a single 
frame.   Internally, we use about 60 different categories, where a 
domain often falls within several.

The NAICS list is impractical for three reasons:
1) its enumeration is not suitable for category aggregation.
2) its categories are unrelated to Internet commerce.
3) its categories don't map into specific handling considerations.

> > Categorization for its own sake should be discouraged.  "It might
> > be nice to know" does not offer suitable justification in the
> > creation and support of a standardized category,
>
>  (3) there are existing taxonomies to be employed.  If you are
>  arguing that (1) is false, then I don't understand the argument yet.

Again, government categorization of business endeavors offers virtually 
nothing about undesired behavior, or whether they conduct sensitive 
online transactions in a specific manner.  In other words, a breakdown 
of behaviors, and general obligations would prove more useful, since 
this could then map into specific handling, such as should TLS 
certificates verify its emitting servers?

With respect to online transactions, what is gained by a reputation 
server claiming an entity represents an acquiring bank, without specific 
types of direct authentication being the basis of the assertion?  Does 
the IETF desire a protocol for Dun and Bradstreet, infoGROUP, Moody's, 
etc.?  Even one of these companies would unlikely be able to offer 
suitable categories for the 200 million companies covered, when not 
paying specific attention to online behaviors.

Unfortunately, most of the specifically relevant categories would relate 
to undesired behaviors.

- network scanning
- spamming
- malware distribution
- phishing
- denial of service attacks
- fast-flux domain activity
- compromised servers
- open proxies
- open relays

With respect to email, some categories that would make sense is whether 
they verify subscriptions, honor unsubscribe requests, or send 
unsolicited messages. To bolster filtering efforts, some categories 
could indicate how a domain is authenticated.  Such authentication 
advice would help counter phishing attempts within exchange sessions.

So what is the reputation service attempting to provide:
  a) a D&B type of service,
  b) authentication advice,
  c) undesired behavior warnings.

No single business category is immune from being compromised, or 
prevents organized crime from acquiring all the related 
infrastructure.   In that regard, a category that indicates some entity 
purports to be an acquiring bank means what exactly?  That it is 
therefore within the fellow-hood of man?  Or that the reputation service 
is also liable for any subsequent domain related bank fraud?

Beyond the single business category that John advocated, what metrics 
can a reputation service use?  How should these metrics be listed?

What would a 0 to 100 rating mean?  Would 0 or 49 mean "unknown", or 
does 0 mean "untouchable"?

What would a 0 to 100 certainty mean?   Would 0 mean "don't know" 
because it is new, or that 0 is due to a recent change in status?

Much of our information goes back many years, and yet some advocated 
only considering information within the last 6 months with respect to IP 
addresses.  Should the same short-term view persist with domains as 
well?  Should the reputation service indicate the duration of its 
information, or that of the domain, or which ever is shorter?

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 17 Aug 2010 15:28:47 -0400

> is from a high value domain."

You could, but now you have yet another level of indirection, in which you 
have to decide whether you agree with my opinion of what is high value and 
what isn't.  Personally, I think that mail from swine farms is very high 
value*, but mail from cameloid farms is down there with newsletters from 
electronics retailers.

R's,
John

* - see http://www.thepiggery.net

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 17 Aug 2010 15:55:52 -0400

>  c) undesired behavior warnings.

I think this is at least the good beginning of the problem statement
for this approach.  Do we have an answer?

> In that regard, a category that indicates some entity purports to be an 
> acquiring bank means what exactly?

Well, wait a minute.  I thought the point of this was to have a
"purports to be" statement, and then a reputation service that rates
that claim according to some reputation-service-proprietary rating
rules.  Maybe I have the model completely wrong?  (Feel free to hit me
with the relevant clue by four.)  It sounds to me like most of the
questions you're asking are on the line of, "How should a
reputation-ranker _use_ this data?" which is (to me) not part of the
remit here.  If that's what we're supposed to be working on, then I
don't think this is work that even remotely belongs in the IETF.
That's not a protocol, and there's no test of interoperation except
"same result," which doesn't even need a protocol.

> can a reputation service use?  How should these metrics be listed?

This sounds to me like an operational question.  See above.

> information, or that of the domain, or which ever is shorter?

Same again.  To begin with, it surely depends on what the history of
the domain itself is.  If it was created 10 minutes ago but happens to
be spelled "mitre.org", you might have reason to be suspicious (FWIW,
I believe that mitre.org is actually the oldest domain in the .org
registry, and whois tells me it was created in 1985).

A

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 Aug 2010 14:26:22 -0700

> Sent: Tuesday, August 17, 2010 12:56 PM
> To: [email-masked]
> Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A
> sketch of a small query reputation system)
> 

Do we have to pick one of those?

I'm not sure that a protocol specification, which I imagine will be the first output of this group, needs to specify any of that.  I suspect we're just going to define a language for making the query and getting the answer.  It would be up to the consumer of the data to decide how to use it, partly based on the goals of the consumer and partly from some a priori knowledge of who's providing the data and what that agency tells you about how the data are prepared.

> "same result," which doesn't even need a protocol.

I totally agree.  I also think how a reputation provider goes about collecting and collating data to use as the report it returns in response to a query is not something the IETF can specify.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 Aug 2010 14:29:09 -0700

> Behalf Of Murray S. Kucherawy
> Sent: Tuesday, August 17, 2010 2:26 PM
> To: [email-masked]
> I totally agree.  I also think how a reputation provider goes about
> collecting and collating data to use as the report it returns in
> response to a query is not something the IETF can specify.

Also, if we're careful, we might be able to do this in a way that doesn't even constrain use of such a protocol to domains.  It could also be used for URLs, IP addresses, restaurants, movies, or anything really.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 17 Aug 2010 17:46:32 -0400

> Do we have to pick one of those?

No, I don't think so.  But it'd be nice to understand what problems we
_must_ solve, what problems we might happily solve if they're nearly
free, and what problems are just out of scope.  

One of Doug's objections I find significant: the proposed taxonomy
doesn't allow multiple categories, which could indeed be troublesome
in cases where an operator has poor "domain hygeine".  (Moreover, the
temptation will be to solve this with "DNS tree climbing", which is
ugly and which will also land us in the usual fight about whether
that's legitimate.  Given the difficulty of detecting zone cuts, I
think it isn't.)

Your downthread remark about specifying the _protocol_ correctly so
that it is properly generic is, I think, still the right impulse.
It's certainly what interests me.

A

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

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 17 Aug 2010 23:57:20 +0200

+1

Nonetheless, I think I understand why Doug comes up with these 
questions: we're trying to define a language/protocol to query 
reputation data, without exactly knowing what that data will look like, 
what elements it will contain. Is it a simple score, or will it be a 
complex reputation field with multiple elements? I have seen various 
elements coming along on this list, proposed by various people, like:

    * Quality of domain
    * Confidence of opinion
    * NAICS code or similar code set
    * Type- or context specific data (web/mail etc.)
    * Generic reputations with details about the kinds of negative
      information they're based on
    * Recency of the bad events
    * (did I forget something?)

Is it possible, without definining the reputation system itself, to 
define what data we'll have to query? Or is one without the other a 
mission impossible? I propose to try to first define a highlevel design, 
without going into the details (goats and pigs etc.) too much. So the 
question is, what would constitute to this high level design? What 
(other, not yet mentioned) characteristics of the reputation data?

/rolf

---

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

Well, DKIM for example defined a general "tag=value" syntax, then declared set of tags it supports (some mandatory, some optional), and then further specified that unknown tags must be ignored.  Maybe a protocol defined here specifies a general syntax and a minimum set of known parameters (e.g. "r=" for the reputation and "c=" for the confidence) and then the rest are either processed or ignored based on what the client knows about the data the server will return.  It's nice and extensible, provides a minimum implementation set, and is fairly easy to parse.

Maybe an IANA registry of tags and their legal values and semantics?

From: Rolf E. Sonneveld [mailto:[email-masked]]
Sent: Tuesday, August 17, 2010 2:57 PM
To: Murray S. Kucherawy
Cc: [email-masked]
Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system)

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On

To: [email-masked]<mailto:[email-masked]>

+1

Nonetheless, I think I understand why Doug comes up with these questions: we're trying to define a language/protocol to query reputation data, without exactly knowing what that data will look like, what elements it will contain. Is it a simple score, or will it be a complex reputation field with multiple elements? I have seen various elements coming along on this list, proposed by various people, like:

 *   Quality of domain
 *   Confidence of opinion
 *   NAICS code or similar code set
 *   Type- or context specific data (web/mail etc.)
 *   Generic reputations with details about the kinds of negative information they're based on
 *   Recency of the bad events
 *   (did I forget something?)
Is it possible, without definining the reputation system itself, to define what data we'll have to query? Or is one without the other a mission impossible? I propose to try to first define a highlevel design, without going into the details (goats and pigs etc.) too much. So the question is, what would constitute to this high level design? What (other, not yet mentioned) characteristics of the reputation data?

/rolf

---

From: Douglas Otis <[email-masked]>
Date: Tue, 17 Aug 2010 17:14:59 -0700

On 8/17/10 3:10 PM, Murray S. Kucherawy wrote:
>
>  Well, DKIM for example defined a general “tag=value” syntax, then
>  declared set of tags it supports (some mandatory, some optional), and
>  then further specified that unknown tags must be ignored. Maybe a
>  protocol defined here specifies a general syntax and a minimum set of
>  known parameters (e.g. “r=” for the reputation and “c=” for the
>  confidence) and then the rest are either processed or ignored based
>  on what the client knows about the data the server will return. It’s
>  nice and extensible, provides a minimum implementation set, and is
>  fairly easy to parse.
>

This approach would not be practical for many protocols.

The Google Safe Browser API offers a working example of an open 
reputation service currently being used by millions of browsers that 
does not leak client information.

The domain's status depends upon which list contains a hash of the 
canonicalized URI. Clearly, the type of protocol specific exchanges 
being protected, dramatically impacts the general structure of the service.

A quibble about how reputation should be generated and applied.

You seem to envision a service that offers a complex function of 
reputation and confidence values, without offering specifics of how this 
information is applied. Clearly, the resulting uncertainty absolves the 
service of subsequent decisions. Such absolution is needed when the 
basis for reputation fails to authenticate the source, but is based upon 
an assumed source. Unfortunately, assumptions regarding the source of a 
message in the generation of reputation is inherently unfair, and is not 
something the IETF should promote.

John gave a recent example of spamming attributed to BofA based upon 
their DKIM signature. Unfortunately, a DKIM signature can be replayed. 
This feature makes it difficult to attribute unsolicited messages to the 
domain applying the DKIM signature. Most likely, the guilty entity for 
sending unsolicited messages was a third-party service provider using 
harvested address lists acting on their behalf, but it could also have 
been from someone wanting to harm their reputation. Giving BofA a 
negative rating on the basis of a DKIM signature or an SPF authorization 
is unlikely to be effective at identifying the acting domain, and likely 
a reason for wanting to hint at the relative importance of the assumed 
source.

White-listing domains is not effective at preventing undesired traffic 
when the domain does not identify the server originating the exchange. 
For reputation to be effective at blocking an entity causing problems, 
it must be based upon the administrative domain of the emitting server. 
Fairness requires that DKIM or SPF information be ignored when it does 
not identify the emitting server when establishing reputation ratings 
based on unsolicited traffic.

Perhaps work being done on the keyassure reflector might result in a 
much needed EHLO authentication scheme. I would be interested in working 
on such an I-D.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 18 Aug 2010 14:06:14 +0200

Douglas Otis wrote:
> unsolicited messages.

IMHO, reputation should stay one level higher than behavior.  A 
classification, if any, must be such that domain owners will agree or propose 
the right class for their domains.

> purports to be an acquiring bank means what exactly?

IMHO, it means that any authenticated bad behavior was either the result of a 
compromised client or an employee acting incorrectly.

Reputation should be related with how well they handle those incidents.  In 
this respect, it is important that classifications reflect if/how 
responsibility for the domain behavior is distributed among registered users 
of the domain.

I disagree that the IETF is unable to specify how reputation may be 
determined.  How and where data is collected and collated may affect how it 
is queried and retrieved.  That data does not exist already, AFAIK.  The 
problem is to build the data, before we can query and retrieve it.

Specifying a protocol that returns a quality triplet for each given token 
(URLs, IP addresses, restaurants, movies, or anything really) may be an 
interesting exercise in its own right.  But it is not the central part of the 
problem.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Aug 2010 10:59:21 -0700

On 8/18/10 5:06 AM, Alessandro Vesely wrote:
> Douglas Otis wrote:
>> Unfortunately, most of the specifically relevant categories would 
>> relate to undesired behaviors.
>>
>> - network scanning
>> - spamming
>> - malware distribution
>> - phishing
>> With respect to email, some categories that would make sense is 
>> whether they verify subscriptions, honor unsubscribe requests, or 
>> send unsolicited messages.
> classification, if any, must be such that domain owners will agree or 
> propose the right class for their domains.
Class?  As in first, second or third?  What would class mean?  If this 
relates to problematic protocols or how domains are authenticated, then 
I might agree.  Reputation should _only_ reflect _verifiable_ and 
_authenticated_ online behavior.  If you're not interested in online 
behavior,  then use a D&B type of service unrelated to online behavior 
at your leisure.  Unfortunately, many corporations become heavily 
compromised, which means ignoring their online behavior would not be 
beneficial.
>> infrastructure.   In that regard, a category that indicates some 
>> entity purports to be an acquiring bank means what exactly?
> IMHO, it means that any authenticated bad behavior was either the 
> result of a compromised client or an employee acting incorrectly.
>
> Reputation should be related with how well they handle those 
> incidents.  In this respect, it is important that classifications 
> reflect if/how responsibility for the domain behavior is distributed 
> among registered users of the domain.
FWIW, reputation based upon online behavior should offer concise results 
that indicate whether a domain should be blocked.  Such a service should 
also offer notifications to affected domains and allow a response before 
escalating to a recommendation of being blocked.
> determined.  How and where data is collected and collated may affect 
> how it is queried and retrieved.  That data does not exist already, 
> AFAIK.  The problem is to build the data, before we can query and 
> retrieve it.
Agreed.  Until email offers a method to authenticate issuing hosts, 
domain reputation is unable to offer much in the way of controlling 
abuse via domain names.  Methods that assume a domain originated a 
message are destine to being gamed out of existence, and are wholly 
unsupportable.
> Specifying a protocol that returns a quality triplet for each given 
> token (URLs, IP addresses, restaurants, movies, or anything really) 
> may be an interesting exercise in its own right.  But it is not the 
> central part of the problem.
Fully agree.

-Doug

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 18 Aug 2010 14:08:44 -0400

On Wed, Aug 18, 2010 at 10:59:21AM -0700, Douglas Otis wrote:

> abuse via domain names.

Again, I think I'm having a hard time understanding you.  Are you
suggesting that domain reputations are useless because they don't
solve a particular email problem?

A

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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Aug 2010 12:03:33 -0700

> solve a particular email problem?
The SMTP protocol, as specified, does not require any domain in a 
transaction to authenticate using some method. Reputation based upon the 
emitting host would not result in any source uncertainty, but there is 
no common practice for authenticating this with SMTP.  I would be happy 
to write an I-D for SMTP Auth using a DKIM key that authenticates the host.

SPF represents an authorization scheme referenced from some email 
element, where authorized servers often handle thousands of domains, and 
where these email elements are not normally nor necessarily bound to 
specific sources.  Many suggest domains should be accountable for 
authorizations, however this would not allow domains a means to correct 
their reputation, nor be assured problems beyond their control do not 
reoccur.  While some domains control the IP addresses and servers used, 
this is not the typical situation.  Bad actors are expert at gaming 
uncertainties, which makes supporting an authorization scheme expensive, 
problematic and ultimately unfair.

DKIM can be replayed by design.  The replay feature makes it a poor 
identifier for controlling unsolicited email, because a valid signature 
does not indicate the intended recipient.

-Doug

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 18 Aug 2010 15:16:55 -0400

> to write an I-D for SMTP Auth using a DKIM key that authenticates the 

So, then, if we _had_ a mechanism for people to, say, look up what you
thought about a given domain, then it might be useful, no?

> DKIM can be replayed by design.

That's at least twice I've seen this assertion in this thread.  What
does it have to do with the rest of the topic?

A

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 18 Aug 2010 12:21:02 -0700

> Sent: Wednesday, August 18, 2010 12:17 PM
> To: [email-masked]

I'm not sure why it's considered a serious threat in the first place.  The best you can do is replay an unmodified (subject to use of "l=") original message.  The worst this can be is annoying, not actually a security worry (e.g. misrepresentation of content or of the originator).

In any case, I don't see how one can include normative text about what domains are valid for querying when we're talking about a protocol.  That seems to me to be as effective as RFC5322 saying the domain provided in the From: header field has to be correct.  We can provide all the informative text about it we want, though.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Aug 2010 13:32:21 -0700

> thought about a given domain, then it might be useful, no?
It would be useful to obtain information specific to how a domain is 
authenticated, and whether it currently is emitting undesired traffic 
not being mitigated.
> does it have to do with the rest of the topic?
The majority of undesired traffic in email relates to "unsolicited" 
messages that are _not_ identified by their content. To be useful, email 
reputation deals with this significant aspect of undesired traffic, or 
it becomes difficult to justify the additional resources expended.  
These processes need to be automated, however a system based upon 
assumed sources allows bad actors an easy method to poison reputation 
information being collected, to the point where the system can not be used.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 19 Aug 2010 11:33:04 +0200

Douglas Otis wrote:
>>> - [other behaviors elided]
>>>
> I might agree.

Probably my English not supporting me.  I just figured a hierarchy of classes 
(categories) and considered /classification/ as the process of assigning a 
class to each domain.  Since the number of domains is huge, that is a 
daunting task.

> Reputation should _only_ reflect _verifiable_ and _authenticated_ online
> behavior.

I don't fully agree, as I see no reason for the "only" requisite.  The core 
of your statement hinges on /how/ reputation reflects online behavior. 
Indeed, working out this point is the central part of the problem that this 
WG-wannabe should elect to solve, IMHO.

>> incidents.
> that indicate whether a domain should be blocked.

Nearly.  IMHO, a receiver should handle with suspicion (or block), messages 
that are either unauthenticated or from domains with no reputation at all. 
If a reputation record can be found, the domain is a cooperative one and mail 
from it should be accepted.  Abusive messages will then go through a 
reputation-driven process, and reputation itself will be adjusted according 
to its outcome.

Abusive web content might be handled similarly.  An additional advantage for 
web sites who register users, will be the ability to reckon the 
trustworthiness of newcomers based on their IDs' domain reputation --for 
"user@domain" IDs.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 19 Aug 2010 17:46:26 +0200

Murray S. Kucherawy wrote:
> confidence) and then the rest are either processed or ignored based on 
> what the client knows about the data the server will return. It’s nice 
> and extensible, provides a minimum implementation set, and is fairly 
> easy to parse.
>

I very much like this proposal as a starting point to design a model, 
which we can use to experiment with (I mean thought-experiments or 
experiments on paper) and which can lead to defining the real protocol. 
To use the 'characteristics' mentioned earlier on this list, the above 
two items:

"r=" for reputation
"c=" for confidence

can be expanded to, for example:

"i=" company or organization category (NAICS or other set)
"t=" type or context, e.g. web, mail, sms, im etc.
"h=" hash value, e.g. to contain the hash for a mail address, or for a 
URL (relative to domainname) etc.
"f=" date/time of first abuse/malware/threat
"l=" date/time of last abuse/malware/threat
"n=" number of sources on which reputation decision is based
"b=" type of information on which reputation is based (spf, dkim, spam 
report, virus report, or whatever)
"e=" expires, maybe we want an expire date
"?=" (I challenge all of us to come up with more characteristics which 
may be important in relation to reputation.)

BTW: Maybe the hash value should not be part of these tags, but instead 
be part of the location in DNS (or whatever mechanism/storage is chosen) 
where the reputation data can be found.

I suggest to start for each and every domain with a zero (0) value for 
reputation, which can grow to some positive value (e.g.) 9 or 99 or 255 
and which can be decreased to some negative number (e.g.) -9, -99 or 
-255. A zero means: don't know, no information, or neutral. Another 
option would be here to use bit-encoded values.

> Maybe an IANA registry of tags and their legal values and semantics?

Yes, IANA registry is important and should be described.

Apart from the above, we need to define:

a) the protocol to be used to retrieve this data: DNS, HTTP, LDAP, MySQL 
or whatever (being DNS the most likely candidate IMHO)
b) the mechanism how c.q. the location where to find the reputation data 
in DNS (or other protocol)
c) security considerations, especially things like risk of DDoS and how 
to defend against it
d) etc.

I'd be happy to make a start with a draft ID in which these things are 
addressed. The above does _only_ address the reputation protocol 
exchange, _not_ how reputation is determined, _nor_ how it's used by the 
reputation 'consumer', _nor_ whether the reputation data can be trusted 
etc., so it's entirely in scope of the discussion, I think.

/rolf

---

From: John Levine <[email-masked]>
Date: 19 Aug 2010 16:56:35 -0000

>"t=" type or context, e.g. web, mail, sms, im etc.
 [ and  laundry list of other stuff ]

This is the dossier model I mentioned.  It seems unlikely to me that
you could reasonably represent all the dossier info using short text
strings (I want ma= for their full postal mailing address), and
equally unlikely that it'll fit in a reasonably sized DNS response.
That's why it's represented using an XML schema (to avoid inventing
yet another complex ad-hoc syntax), and fetched using something like
SOAP (to avoid inventing yet another heavyweight query scheme.)

When I suggested that a short response should include a triple of
score, confidence, and organization type, those weren't picked at
random.  They're the things that everyone (at the time) said they
wanted.

I'm not opposed to a dossier model, but I think it's important to
distinguish between a fast lightweight model that's easy to use in
realtime filtering because it has a small set of known fields, and a
dossier that pretty much has to be stirred into an overall scoring
system.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Aug 2010 10:01:05 -0700

> Behalf Of John Levine
> Sent: Thursday, August 19, 2010 9:57 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [domainrep] respponse bloat, was Industry taxonomies such
> as NAICS
> 

There are also the obvious transport issues: The short model is fully resolved and easily parsed with a single UDP DNS query, while anything bigger than that will require either TCP DNS, or a full HTTP/XML/SOAP setup (or similar) with somewhat more expensive parsing.

One could certainly offer both, and we could specify the syntax of both as well, to accommodate both worlds.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Aug 2010 10:06:04 -0700

> Sent: Thursday, August 19, 2010 2:33 AM
> To: [email-masked]

I still don't see how the IETF can specify how one goes about collecting and collating data to put into a reputation report of any kind.  This makes about as much sense to me as the IETF specifying how one filters spam; there are countless algorithms, some effective and some not, some prone to false positives and some not.  There is no "right" mechanism; instead, people vote with their proverbial feet as particular algorithms prove (or fail to prove) their efficacy.

The mechanism by which one presents an object for evaluation and gets a report about it is a matter of protocol, and we can specify that.  The rest is what I've been calling "secret sauce" and we have no business meddling in that area, nor can we possibly think stipulating how one picks what objects to present for evaluation, in a normative sense, is even worth trying to do.

I do, however, think providing as part of the report some hints about how the results were determined might be useful.

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 19 Aug 2010 10:10:46 -0700

On Aug 19, 2010, at 8:46 AM, Rolf E. Sonneveld wrote:

> I'd be happy to make a start with a draft ID in which these things are addressed. The above does _only_ address the reputation protocol exchange, _not_ how reputation is determined, _nor_ how it's used by the reputation 'consumer', _nor_ whether the reputation data can be trusted etc., so it's entirely in scope of the discussion, I think.

[as co-chair]  I agree -- and many thanks for the offer.  I think it'd help everyone immensely to see this part of the discussion codified into a draft, so we can look at it as a whole.

[replying as a participant for the remainder]

>> Well, DKIM for example defined a general “tag=value” syntax, then declared set of tags it supports (some mandatory, some optional), and then further specified that unknown tags must be ignored. Maybe a protocol defined here specifies a general syntax and a minimum set of known parameters (e.g. “r=” for the reputation and “c=” for the confidence) and then the rest are either processed or ignored based on what the client knows about the data the server will return. It’s nice and extensible, provides a minimum implementation set, and is fairly easy to parse.
> 
> I very much like this proposal as a starting point to design a model, which we can use to experiment with (I mean thought-experiments or experiments on paper) and which can lead to defining the real protocol. To use the 'characteristics' mentioned earlier on this list, the above two items:
> 
> "r=" for reputation
> "c=" for confidence
> 

Probably also need a tag (and an IANA registry) to identify which categorization authority is being used.

> "t=" type or context, e.g. web, mail, sms, im etc.

Would it be sufficient to use URI scheme names here?

> "h=" hash value, e.g. to contain the hash for a mail address, or for a URL (relative to domainname) etc.

Does it have to be hashed?  I can imagine valid arguments either way....

> "b=" type of information on which reputation is based (spf, dkim, spam report, virus report, or whatever)
> "?=" (I challenge all of us to come up with more characteristics which may be important in relation to reputation.)

I challenge all of us to keep the number of default characteristics to a minimum.  *grin*

Also, I imagine most of these are optional?  I wouldn't want to create a protocol that can't be used to convey exactly the same data as all the existing systems.

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 19 Aug 2010 10:16:47 -0700

> random.  They're the things that everyone (at the time) said they

I'd expect once we've got the initial list of fields -- in any form -- it'll be easier to see what works as tag=value and what needs XML.

I could easily imagine one of the tags containing an HTTP URL to a SOAP service which contains more detailed info, for use when those details are desired...but I'm not so certain that those details will actually be used for anything except manual debugging processes.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Aug 2010 10:28:08 -0700

> Behalf Of J.D. Falk
> Sent: Thursday, August 19, 2010 10:11 AM
> To: [email-masked]
> Subject: [domainrep] towards a first draft (was Re: Industry taxonomies
> such as NAICS (was Re: A sketch of a small query reputation system))
> 

Is there a registered URI prefix for SMS or IM?

> Does it have to be hashed?  I can imagine valid arguments either

I'm not sure I understand the need for this one at all.  Doesn't this mean the server is replying to the client with a hash of the question it was asked?  What would that be for?

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 19 Aug 2010 19:49:29 +0200

> Would it be sufficient to use URI scheme names here?

The idea is attractive, but I don't think it will cover all possible 
contexts.

> Does it have to be hashed?  

Not necessarily.

> I can imagine valid arguments either way....
>   

Agreed. Let's sideline it for a moment, to discuss this later.

> I challenge all of us to keep the number of default characteristics to a minimum.  *grin*

+1. It was not my intention to make the list as long as possible, I only 
wanted to appeal on the creativity of all of us, as we were running more 
or less in circles, without exploring any other possibly important 
aspects of reputation. So I fully agree: the list should be as short as 
possible - but not shorter.
> Also, I imagine most of these are optional?  I wouldn't want to create a protocol that can't be used to convey exactly the same data as all the existing systems.

I'm pretty sure that we will see that most of them are optional, having 
the two or three mentioned by John as the mandatory tags/fields (I'm not 
sure the industry/taxonomy tag needs to be defined as mandatory).

/rolf

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 Aug 2010 11:06:23 -0700

On 8/19/10 10:06 AM, Murray S. Kucherawy wrote:
 > On 8/18/10 1:32 PM, Douglas Otis
> > On Thursday, August 19, 2010 2:33 AM Alessandro Vesely wrote:
> >> Reputation should _only_ reflect _verifiable_ and
> >> _authenticated_ online behavior.
> >
> > I don't fully agree, as I see no reason for the "only" requisite.
> > The core of your statement hinges on /how/ reputation reflects
> > online behavior. Indeed, working out this point is the central part
> > of the problem that this WG-wannabe should elect to solve, IMHO.
>
>  I still don't see how the IETF can specify how one goes about
>  collecting and collating data to put into a reputation report of any
>  kind.

The draft should require data collected that negatively affects a 
domain's reputation be authenticated.

>  This makes about as much sense to me as the IETF specifying how one
>  filters spam; there are countless algorithms, some effective and some
>  not, some prone to false positives and some not.  There is no "right"
>  mechanism; instead, people vote with their proverbial feet as
>  particular algorithms prove (or fail to prove) their efficacy.

Not being able to provide evidence justifying a domain's reputation 
represents a likely disruptive and unfair service.  In principle, the 
basis for negative reputation MUST be authenticated.  For IP addresses, 
this might include a TCP exchange of several packets.  For Domains this 
should be specified for each type of protocol assessed for specific 
behaviors.

>  The mechanism by which one presents an object for evaluation and gets
>  a report about it is a matter of protocol, and we can specify that.

Agreed.

>  The rest is what I've been calling "secret sauce" and we have no
>  business meddling in that area, nor can we possibly think stipulating
>  how one picks what objects to present for evaluation, in a normative
>  sense, is even worth trying to do.

Would you be happy having your DOMAIN blocked by a service that is not 
obligated to offer any authenticated evidence justifying the negative 
ratings given for your DOMAIN?  The magnitude of a rating is not 
important. However, the range of values representing negative 
reputations, and values that represents an "unknown" reputation MUST be 
specified.

>  I do, however, think providing as part of the report some hints about
>  how the results were determined might be useful.

Hints?

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Aug 2010 11:16:58 -0700

> Behalf Of Douglas Otis
> Sent: Thursday, August 19, 2010 11:06 AM
> To: [email-masked]

How is that part of a protocol design and not an implementation decision?

> represents a likely disruptive and unfair service.

...which people would avoid by seeking that service from some other provider.

This doesn't belong in a protocol specification.

> ratings given for your DOMAIN?

Yes.  If people want mail from my domain and they find some reputation provider is giving my domain a negative rating with no basis, they will either whitelist me or find a more accurate provider.  This is not a new concept; think RBLs.

Justifying it in the answer is fine.  Regulating how a provider comes up with the answer does not belong in a protocol specification.

> The magnitude of a rating is not

Sure, THAT is a valid part of a protocol specification.

---

From: John Levine <[email-masked]>
Date: 19 Aug 2010 18:56:14 -0000

>Is there a registered URI prefix for SMS or IM?

For SMS, RFC 5724 defines the sms: URI.  For IM, RFC 3860 defines the im:
URI.

I have my doubts as to how useful this would be in a reputation lookup,
but there's no need to reinvent them if so.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 20 Aug 2010 11:48:41 +0200

Murray S. Kucherawy wrote:
>> From: Alessandro Vesely
>>> Reputation should _only_ reflect _verifiable_ and _authenticated_ 
>>> online behavior.
> I still don't see how the IETF can specify how one goes about collecting 
> and collating data to put into a reputation report of any kind.

Nor I.  But that's because we haven't worked out that point, yet.  However, 
there is a decent understanding of how generalized FBLs can be standardized, 
and that part may somehow include details about how to select a reputation 
tracker.

> filters spam; there are countless algorithms, some effective and some not, 
> some prone to false positives and some not.  There is no "right" 
> mechanism; instead, people vote with their proverbial feet as particular 
> algorithms prove (or fail to prove) their efficacy.

Yes, the IETF might standardize Bayesian filters, since they are already 
specified.  And that is not a cooperative process.  OTOH, MARID has proved 
that a specifications not invented within the IETF have fewer possibilities 
of being standardized either.

A possible solution is that this group agrees on a cooperation model.  What 
will be standardized are the interfaces whereby cooperation may be achieved.

> The mechanism by which one presents an object for evaluation and gets a 
> report about it is a matter of protocol, and we can specify that.

Yes, querying is one of those interfaces.

> The rest is what I've been calling "secret sauce" and we have no business 
> meddling in that area,

How much will it cost to discover all domains and subdomains and classify 
them according to NAICS?  How much will they have to charge in order to reach 
a break even after N years?  It is not realistic _not_ to ask these questions.

> nor can we possibly think stipulating how one picks what objects to 
> present for evaluation, in a normative sense, is even worth trying to do. 
> I do, however, think providing as part of the report some hints about how 
> the results were determined might be useful.

Yes, we agreed something similar about suggesting how to determine whether it 
  is safe to forward an abuse report to some site.  Hopefully, the two sets 
of suggestions will match with one another :-)

---

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

On 8/19/10 11:16 AM, Murray S. Kucherawy wrote:
> > On Thursday, August 19, 2010 11:06 AM Douglas Otis wrote:
> >

This type of statement should be within the Security Consideration section.

George Fuechsel's expression Garbage In, Garbage Out applies in this 
case.  Allowing garbage in (assumed sources) will result in denial of 
service issues.  While no RFC really prevents ill advised practices, at 
least it should include guiding principles such as "data used to assign 
negative reputations MUST be authenticated".  Bad actors do and will 
attempt to poison a system that interferes with their activities.

> > Not being able to provide evidence justifying a domain's
> > reputation represents a likely disruptive and unfair service.
>

Strongly disagree.  Not authenticating data used to establish negative 
reputations represents a security issue when this potentially disrupts 
an ENTIRE DOMAIN without them having any effective recourse!

> > Would you be happy having your DOMAIN blocked by a service that is
> > not obligated to offer any authenticated evidence justifying the
> > negative ratings given for your DOMAIN?
>
>  Yes.  If people want mail from my domain and they find some
>  reputation provider is giving my domain a negative rating with no
>  basis, they will either whitelist me or find a more accurate
>  provider.  This is not a new concept; think RBLs.

RBLs typically involved reputations based upon the end point of TCP 
traffic from a particular IP address, where in our case, this also 
involved monitoring BGP and retaining evidence supporting our 
assertions.  Domains however deserve even greater care.  The draft 
should clearly make this point.

>  Justifying it in the answer is fine.  Regulating how a provider comes
>  up with the answer does not belong in a protocol specification.

Saying that the data should be authenticated does not necessarily 
indicate how.

> > The magnitude of a rating is not important. However, the range of
> > values representing negative reputations, and values that
> > represents an "unknown" reputation MUST be specified.
>

Great.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 21 Aug 2010 12:02:52 +0200

> should be specified for each type of protocol assessed for specific 

Correct.  However, negative contributions to a domain's reputation should be 
exceptional means to reproach that domain's admins, e.g. in case they fail to 
properly handle an incident.

> reputations, and values that represents an "unknown" reputation MUST be 

There is no point in setting global negative values for a domain's 
reputation.  Persistent abusers will just change to new domain names. 
Reputation must reflect good behavior.

How do we establish a new domain's positive reputation?  Let me draw a 
tentative sketch:

   The admins of ND.example fill out a simple module aimed at determining ND's
   position in our taxonomy.  Some other domains, which we may call ND's
   "friends", check the answers given, and reward their correctness with a
   score.  These scores contribute to the ND's reputation.  In order to avoid
   gaming, ND's reputation will have different values according to the /web of
   trust/ of the enquirer: when one of the friend domains queries ND's
   reputation, the score they gave to it is preponderant;  However, if there
   is no trust-path from an enquirer to the ND's friends, the enquirer sees no
   reputation at all.

--

---

From: Nathaniel Borenstein <[email-masked]>
Date: Sun, 22 Aug 2010 13:56:29 -0400

The more I read about NAICS and its ilk, the more I feel like going back to first principles.  Why do we need an industry code, and what does it mean?   Is there a meaningful industry code for a company like IBM, that plays in nearly every part of the computer industry, or GE, which plays a huge variety of roles in many industries?  Do we really want or need to base reputations (and ensuing actions) on the best-fit industry role that someone -- we still don't know who or how or when -- has selected for a company?   And can we really justify the cost of everyone taking the time to decide on these industry codes?   This all feels like a rathole to me.

Perhaps we should instead work towards a taxonomy of the particular (behavioral) attributes about which we're reporting reputation information.  In the real world, if I had to choose between two people, one of whom was a known financial criminal and one of whom was a known child molester, I would choose the former in a heartbeat if I was looking a babysitter for my children.  But if I was looking for someone to mind my lemonade stand while I took a break, I might well go with the pervert.  And none of this criminal information would be helpful in trying to decide whether or not to accept email from one of their private domains.  (A kiddie porn website that behaves well in terms of malware probably deserves a very limited kind of good reputation.)

So I find myself wondering:  Perhaps we should be worrying about taxonomizing threat types rather than industry codes?  Then we might say that ge.com has a good reputation for not sending spam, but (in a whimsical future extension) a bad reputation for overcharging consumers on credit card fees.  A particular ISP might have a good reputation for responding quickly to incident reports, but a bad reputation for keeping spam out of its outgoing mail.   And so on.

I'm guessing that the desire for industry codes is really motivated by a few specific use cases that might just as well be handled by a threat taxonomy.  Instead of identifying citibank.com as some kind of bank, we could just make it possible to say that it has an extremely low score on pretending falsely to be a bank, which is one of the (relatively few, compared with NAICS categories) specific threats we're worried about.  -- Nathaniel

---

From: John Levine <[email-masked]>
Date: 23 Aug 2010 02:35:36 -0000

>I'm guessing that the desire for industry codes is really motivated by a
>few specific use cases that might just as well be handled by a threat
>taxonomy.

I don't think so.  Banks are a somewhat unusual case in that they tend
to be phish targets, and that in most countries they are regulated by
the government so it is possible to get a definitive list of the
genuine banks.  (Yes, there are arcane corner cases.  A reputation
system does not have to cover the entire universe, so it doesn't
matter.)  I want to know is "this is a bank", not "this is an entity
that has not been observed to send bank phishes."  If I know mail is
really from a bank, I might want to deliver it even if it smells
spammy since the potential damage of doing so is low.  Note that a
rather coarse taxonomy is fine here, it's unlikely to be useful to
know the difference among the zillion types of central European banks
that Stephen mentioned.

I'm not sure what other categories are likely to be sufficiently
interesting to be worth checking the code, but it's probably more
likely that they already have a NAICS code than that they have one
in a taxonomy that we nerds make up.

It might be useful to have a separate flag that says "this isn't a
phish", but I see that as a separate axis from what sort of entity the
sender is.  Or maybe any entity that's well enough identified to assign
an organization code is by definition not a phish.

R's,
John

---

From: Nathaniel Borenstein <[email-masked]>
Date: Mon, 23 Aug 2010 08:20:26 -0400

Well, my bottom line remains the same:  If we want a half dozen or so categories of institutional descriptions, do we really need to achieve this by buying in to a taxonomy like NAICS that gives us thousands of categories we don't want?  That's the appeal to me of itemizing threats instead -- we would confine ourselves to the things we actually care about.    I'm open to other ways of achieving that, but I'm really skittish about adopting a big taxonomy (let alone one outside our control) if we don't need 99% of it. -- Nathaniel

PS -- I think "we nerds" are arguably the *best* people to itemize types of threats, if not to define categories of enterprises. -- nsb

---

From: "John R. Levine" <[email-masked]>
Date: 23 Aug 2010 08:25:10 -0400

> Well, my bottom line remains the same:  If we want a half dozen or so 
> categories of institutional descriptions, do we really need to achieve 
> this by buying in to a taxonomy like NAICS that gives us thousands of 
> categories we don't want?

Since we have very little experience doing this, I dunno.  But at least as 
a strawman, NAICS has two practical advantages.  One is that the codes are 
of variable length, and if it turns out that a coarse taxonomy is indeed 
adequate, we can just look at the first two or three digits.  The other is 
that it actually exists and gives us something we can use for experiments.

> PS -- I think "we nerds" are arguably the *best* people to itemize types 
> of threats, if not to define categories of enterprises. -- nsb

Sure.  We know way more about online threats than we do about categories 
of organizations.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Mon, 23 Aug 2010 13:41:26 -0700

On 8/23/10 5:25 AM, John R. Levine wrote:
>> categories of institutional descriptions, do we really need to 
>> achieve this by buying in to a taxonomy like NAICS that gives us 
>> thousands of categories we don't want?
> Since we have very little experience doing this, I dunno.  But at 
> least as a strawman, NAICS has two practical advantages.  One is that 
> the codes are of variable length, and if it turns out that a coarse 
> taxonomy is indeed adequate, we can just look at the first two or 
> three digits.  The other is that it actually exists and gives us 
> something we can use for experiments.
John,

I agree with Nathaniel.  NAICS is not concise enough.  Its thousands of 
categories is not representative of a practical list.  Is the two digit 
category of "52 Finance and Insurance" sufficient?  After all, "522 
Credit Intermediation and Related Activities" does not seem to be 
something better understood by those maintaining email acceptance 
criteria.  In reality, a useful category could be whether a domain 
exchanges "commerce with sensitive information" likely to become a 
phishing target. By constraining the number of categories asserted with 
a flag bit, this allows simultaneous categories.  Such as "commerce 
recognized by government agencies" could be added to Finance and 
Insurance, or to Public Administration (fire, police, etc.).

bit 0 Agriculture, Forestry, Fishing and Hunting
bit 1 Mining, Quarrying, and Oil and Gas Extraction
bit 2 Utilities,
bit 3 Construction,
bit 4 Manufacturing,
bit 5 Wholesale Trade,
bit 6 Retail Trade,
bit 7 Transportation and Warehousing,
bit 8 Information,
bit 9 Finance and Insurance
bit 10 Real Estate, Rental and Leasing
bit 11 Professional, Scientific and Technical Services,
bit 12 Management of Companies and Enterprises,
bit 13 Administrative and Support and Waste Management and Remediation 
Services
bit 14 Educational Services,
bit 16 Health Care and Social Assistance,
bit 17 Arts, Entertainment, and Recreation,
bit 18 Accommodation and Food Services,
bit 19 Other Services (except Public)
bit 20 Public Administration

bit 21 Verifies Subscriptions
bit 22 Handles Sensitive Transactions
bit 23 Governmental domain recognition
bit 24 Bonded or Insured
bit 25 Open Proxy
bit 26 Open Relay
bit 27 Originating Identities Not Checked
bit 28 Bulk Solicits Without Subscription
bit 29 Cryptographically Authenticates

>> PS -- I think "we nerds" are arguably the *best* people to itemize 
>> types of threats, if not to define categories of enterprises. -- nsb
> Sure.  We know way more about online threats than we do about 
> categories of organizations.
Which suggests that these efforts should be constrained to bits >20?

-Doug

---

From: Nathaniel Borenstein <[email-masked]>
Date: Tue, 24 Aug 2010 09:42:58 -0400

Perhaps we could at least take a first stab at a threat taxonomy, to see if what we end up with is more or less appealing than a NAICS type of taxonomy?  (And of course they're not mutually exclusive, either, but I'd rather simplify than make this more complex.)

I think there's a lot to be said for a few, highly logical top-level categories, with a possible proliferation of subcategories.  Off the top of my head, here are four categories of things I'd like to know whether or not a domain is reputed to be guilty of, along with a sampling of possible subcategories

	-- sending unsolicited bulk email (subcategories might include fraud)
	-- sending email with false/deceptive sender information (subcategory: claiming falsely to be a trusted institution, perhaps with financial and other sub-subcategories)
	-- sending active malware content (several subcategories possible)
	-- failure to maintain best practices for email servers (possible subcategories for open relays, Non-responsiveness (or unacceptably slow response) to abuse reports, etc.)

I'm sure there are others, but this seems like a very actionable kind of information, which is what I think we need.  -- Nathaniel

On Aug 23, 2010, at 4:41 PM, Douglas Otis wrote:

>>> Well, my bottom line remains the same:  If we want a half dozen or so categories of institutional descriptions, do we really need to achieve this by buying in to a taxonomy like NAICS that gives us thousands of categories we don't want?
>> Since we have very little experience doing this, I dunno.  But at least as a strawman, NAICS has two practical advantages.  One is that the codes are of variable length, and if it turns out that a coarse taxonomy is indeed adequate, we can just look at the first two or three digits.  The other is that it actually exists and gives us something we can use for experiments.
> John,
> 
> I agree with Nathaniel.  NAICS is not concise enough.  Its thousands of categories is not representative of a practical list.  Is the two digit category of "52 Finance and Insurance" sufficient?  After all, "522 Credit Intermediation and Related Activities" does not seem to be something better understood by those maintaining email acceptance criteria.  In reality, a useful category could be whether a domain exchanges "commerce with sensitive information" likely to become a phishing target. By constraining the number of categories asserted with a flag bit, this allows simultaneous categories.  Such as "commerce recognized by government agencies" could be added to Finance and Insurance, or to Public Administration (fire, police, etc.).
> 
> bit 13 Administrative and Support and Waste Management and Remediation Services
>> Sure.  We know way more about online threats than we do about categories of organizations.

---

From: John Levine <[email-masked]>
Date: 24 Aug 2010 15:12:07 -0000

>Perhaps we could at least take a first stab at a threat taxonomy, to
>see if what we end up with is more or less appealing than a NAICS
>type of taxonomy?

A threat taxonomy is a fine idea, but it's orthogonoal to an
organization taxonomy.  There are banks that send spam, and ESPs that
don't.

>be guilty of, along with a sampling of possible subcategories
>

Huh?  Bulk and fraud are separate.  You can have either without the other.

>	-- sending email with false/deceptive sender information (subcategory: claiming
>falsely to be a trusted institution, perhaps with financial and other
>sub-subcategories)

I see those as functionally separate; fraud to sneak unwanted but
otherwise harmless content into inboxes (Gevalia type spam) vs. fraud
to enable crime.

>	-- failure to maintain best practices for email servers (possible subcategories
>for open relays, Non-responsiveness (or unacceptably slow response) to abuse
>reports, etc.)

Beyond concrete items like relaying mail for stranges, that seems too
subjective to be useful.

R's,
John

---

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

On Aug 21, 2010, at 3:02 AM, Alessandro Vesely wrote:

> However, negative contributions to a domain's reputation should be exceptional means to reproach that domain's admins, e.g. in case they fail to properly handle an incident.

That's human policy -- a value judgement, not a technical standard.

>> Would you be happy having your DOMAIN blocked by a service that is not obligated to offer any authenticated evidence justifying the negative ratings given for your DOMAIN?  The magnitude of a rating is not important. However, the range of values representing negative reputations, and values that represents an "unknown" reputation MUST be specified.
> 
> There is no point in setting global negative values for a domain's reputation.  Persistent abusers will just change to new domain names. Reputation must reflect good behavior.

That's also a value judgement.

A fully open, universally applicable standard will also work for implementors whose value judgements we might personally disagree with.

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 24 Aug 2010 09:43:53 -0700

> Perhaps we could at least take a first stab at a threat taxonomy, to see if what we end up with is more or less appealing than a NAICS type of taxonomy?  (And of course they're not mutually exclusi…

We did that for ARF -- it was a loose taxonomy of things one might complain about, which is very similar.  Even with pressure to keep the list small, we ended up removing nearly all of the types because nobody used them.

> 	-- failure to maintain best practices for email servers (possible subcategories for open relays, Non-responsiveness (or unacceptably slow response) to abuse reports, etc.)

Say we've got a DKIM d= domain in each of these categories.  How/why would an MTA treat them differently?

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 24 Aug 2010 20:08:54 +0200

J.D. Falk wrote:
>> There is no point in setting global negative values for a 
>> domain's reputation.  Persistent abusers will just change to
>> new domain names. Reputation must reflect good behavior.
>

A human or site policy might state that, say, a score of 4.5 is 
sufficient to reject or discard messages from a domain whose trust 
rating is less than 0.1.

Likewise, a policy may state that messages will be rejected from a 
domain flagged with the value (taken from Nataniel's threat 
taxonomy) of "sending unsolicited bulk email".

Even if both examples express value judgements, their underlying 
conceptual models are very different.  The first example presumes 
that domains' reputations are adjusted according to behavior, so as 
to measure their cooperativeness.  The second example, by setting 
negative values, implies the whack-a-mole model.

> A fully open, universally applicable standard will also work for
> implementors whose value judgements we might personally disagree 
> with.

Fully agreed.  Yet, saying that reputations hold positive values 
--much like distances or weights-- is not a question of opinions: it 
is a modeling decision.  Shall we make it?

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 26 Aug 2010 15:58:30 +0200

> Say we've got a DKIM d= domain in each of these categories.  How/why would an MTA treat them differently?

I'd like to chime in here, as I'm currently trying to assemble 
information circulated within this group to write a draft. I have not 
seen a reply to the questions of JD and it makes me wonder whether this 
question might be hard to answer?

I have thought about this and I'd like to make two remarks:

1. I have absolutely no problem with the proposal of Nathaniel, but when 
we start talking about subcategories of subcategories, in my view the 
definition of such a taxonomy should be part of the XML variant of the 
reputation format. I'm referring here to the original thread started by 
John about small domain reputations (small query reputation system) and 
large domain reputations (large query reputation system?). I think the 
conclusion was that there is room for multiple types of query reputation 
systems and associated transports. The first two identified were:

tag=value format + DNS transport
XML format + SOAP/HTTP transport

So to get back to the threat taxonomy, I suggest to define it in the 
context of a large query system, but not in the context of the small 
one. If someone thinks it fits in a small query system, then please 
suggest how the sub-sub-categories should be addressed.

2. talking about a threat taxonomy, I'd like to suggest to change the 
definition of the various categories, that the category name does not 
imply only negative reputation. For example: I can imagine that there 
are organizations which are interested to know whether a sending domain 
has a positive reputation in the area of malware: companies like Sophos 
and organizations like CERT get a positive reputation here.

Of course I know that it's too simple to just trust all mail from such 
organizations, but it's possible that their positive reputation can be 
used as one of many criteria to judge, for the Domain Reputation 
Assessor. So values can range for example from -10 to +10, instead of 
from 0 to -10.

/rolf

---

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

On 8/26/10 6:58 AM, Rolf E. Sonneveld wrote:
>>> type of taxonomy?  (And of course they're not mutually exclusive, 
>>> either, but I'd rather simplify than make this more complex.)
>> We did that for ARF -- it was a loose taxonomy of things one might 
>> complain about, which is very similar.  Even with pressure to keep 
>> the list small, we ended up removing nearly all of the types because 
>> nobody used them.
The MARF (or ARF) RFC only relates to email and does not categorize 
reported abuse, such as whether it involves security related issues 
which could include malware or phishing attempts.  Instead, reporting 
depends upon the message as being self explanatory.  This means MARF 
offers little in the way of useful categories, particularly when even 
the Reported-URI or Reported-Domain are ill defined.

For URI:
,---
Furthermore, it is outside the scope of this standard whether the data 
carried in this field implies any additional information. Implementors 
may negotiate their own agreements surrounding the interpretation of 
this data.
'---
For Domain:
,---
It is unspecified how the report generator determines this information, 
and thus the report receiver cannot be certain how it was chosen. It is 
often used as a means of suggesting to the report receiver how this 
report might be handled.
'---

When IPv6 email acceptance depends upon cryptographic host name 
confirmations for systems relaying messages, this format will need 
domain to be better defined.

See:
http://www.iana.org/assignments/marf-parameters/marf-parameters.xhtml
>>> I think there's a lot to be said for a few, highly logical top-level 
>>> categories, with a possible proliferation of subcategories.  Off the 
>>> top of my head, here are four categories of things I'd like to know 
>>> whether or not a domain is reputed to be guilty of, along with a 
>>> sampling of possible subcategories
>>>
>>>     -- sending email with false/deceptive sender information 
>>> (subcategory: claiming falsely to be a trusted institution, perhaps 
>>> with financial and other sub-subcategories)
>>>     -- failure to maintain best practices for email servers 
>>> (possible subcategories for open relays, Non-responsiveness (or 
>>> unacceptably slow response) to abuse reports, etc.)
> seen a reply to the questions of JD and it makes me wonder whether 
> this question might be hard to answer?
>
> 1. I have absolutely no problem with the proposal of Nathaniel, but 
> when we start talking about subcategories of subcategories, in my view 
> the definition of such a taxonomy should be part of the XML variant of 
> the reputation format. I'm referring here to the original thread 
> started by John about small domain reputations (small query reputation 
> system) and large domain reputations (large query reputation system?). 
> I think the conclusion was that there is room for multiple types of 
> query reputation systems and associated transports. The first two 
> identified were:
>
This type of structure is unsuitable for dealing with domain or URI 
related information without a definition of registration domains, such 
as TLDs, or SLDs, to only permit the next level for initial queries, or 
a scheme where the entire database is routinely transferred in some 
incrementally updating form.  Don't limit "small scale" to only using DNS.

A small scale service based upon a simple query answer structure should 
be considered appropriate only for source IPv4 address reputations.   
Domain, URI, nor IPv6 will scale without bounding the initial query 
which then requires subsequent queries to complete the transaction when 
using DNS.  The additional round trips will likely become problematic.
> XML format + SOAP/HTTP transport
This type of structure is unsuitable for dealing with domain or URI 
related information without a strategy to cache and distribute the data, 
and a means to protect servers from abuse.  This is a real design challenge.
> suggest how the sub-sub-categories should be addressed.
Something along the lines of RFC5070 would likely represent a better 
starting point for general purpose reputation services.

http://tools.ietf.org/html/rfc5070

See section 3.10.1 Impact Class

type
Required.  ENUM.  Classifies the malicious activity into incident
categories.  The permitted values are shown below.  The default
value is "other".

1.   admin.  Administrative privileges were attempted.

2.   dos.  A denial of service was attempted.

3.   file.  An action that impacts the integrity of a file or
      database was attempted.

4.   info-leak.  An attempt was made to exfiltrate information.

5.   misconfiguration.  An attempt was made to exploit a mis-
      configuration in a system.

6.   policy.  Activity violating site's policy was attempted.

7.   recon.  Reconnaissance activity was attempted.

8.   social-engineering.  A social engineering attack was
      attempted.

9.   user.  User privileges were attempted.

10.  unknown.  The classification of this activity is unknown.

11.  ext-value.  An escape value used to extend this attribute.
      See Section 5.1.

> are organizations which are interested to know whether a sending 
> domain has a positive reputation in the area of malware: companies 
> like Sophos and organizations like CERT get a positive reputation here.
Sorry, but no domain is immune.  Any domain can be compromised, be it 
little or large.  Some may decide to ignore a significant level of abuse 
being emitted whenever the domain is considered too large, and likely to 
create support issues when normal commerce becomes disrupted.
> Assessor. So values can range for example from -10 to +10, instead of 
Do you mean for the small scale solution instead of values 0 to 10?  
Perhaps this could be +127 to -128 using an address octet as a signed 
2's complement number, for example.  Using signed 2's complements for 
+100 to -100 would be 0x64 to 0x9C, where 0 would be 0.

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 27 Aug 2010 13:56:34 -0700

(as a participant)

On Aug 26, 2010, at 6:58 AM, Rolf E. Sonneveld wrote:

> I'd like to chime in here, as I'm currently trying to assemble information circulated within this group to write a draft. I have not seen a reply to the questions of JD and it makes me wonder whether this question might be hard to answer?

I think you're right -- and part of the reason is that outside of blacklists (rejection or temporary rejection) and whitelists (overriding other spam filters), we as an industry don't have a lot of experience with defining more complex policies.

Lacking that experience, I think it'll continue to be difficult for us to figure out exactly which types of information will be needed for a complex policy.  Instead, we may be more successful if we skip that part, and focus on a protocol which could communicate a value for ANY information regarding a particular identifier (likely a domain name.)  Then, let the Reputation Providers and Reputation Clients work out which information they want to provide or consume.