Subject: Re: [domainrep] Appropriate choice of identity

From: Dave CROCKER <[email-masked]>
Date: Tue, 13 Dec 2011 07:33:24 -0800

Folks,

On 11/13/2011 10:44 AM, David F. Skoll wrote:
> Just a question that may seem strange or naive at this stage, but:
>
> Who decided that a domain name is an appropriate identity for reputation
> with respect to email?

Unless I missed it, there does not seem to be a response to your original 
question.  The thread that ensued was perhaps interesting, but I didn't see it 
answer this.

At the beginning of an activity like the Repute working group, it's often useful 
to explore these sorts of foundational questions.

They can, of course, become distracting, but a bit of exploration by the group 
might help folks develop a better, shared sense of what motivates the group's 
work.  Getting that into the mailing list archive can also be helpful for other 
folks, later.  (One can also imagine the result of such a discussion helping to 
flesh out the Introduction to a background or framework document, such as our 
own -model.)

So... why a domain name?

He's my own effort to prime the pump on the background for this effort...

In terms of the mechanics of fielding exemplar uses, both SPF and Domainkeys 
(Yahoo!) are early examples of various folk deciding to use domain names, with 
quite a bit of the anti-abuse technical community lining up in support of that 
choice as time progressed.  I don't recall seeing any real controversy about the 
choice, within that community.

Problem with existing practice:  IP Addresses
---------------------------------------------

IP Addresses have been the dominant identifier in the anti-abuse game.  It is 
available at connection setup time and it has some degree of validation, by 
virtue of being supplied out of band.  However there are some very serious 
drawbacks in the choice:

    *  Instability -- Since they are linked to network topology rather than 
organizational boundaries; they typically belong to the organization's service 
provider and not the organization, and they get re-assigned.

    *  Ambiguity -- They often cover multiple users/organizations and therefore 
create ambiguity in the reputation analysis.

    *  Obscurity -- IPv6 introduces an additional, looming nightmare for use of 
IP Addresses as reputation identifiers; it massively increased address space 
provides much greater opportunity for bad actors to hide, by using new addresses 
at a high rate.

    *  Spoofing -- Although not common, IP Addresses can be spoofed.

Choosing an Alternative:  Domain Names
--------------------------------------

Now to the theoretical phase of the question, which goes something like "so, why 
use domain names"?

A passive aggressive response is "what other choice is there, given that IP 
Addresses are problematic?"  It leaves the task of proposing and promoting an 
alternative to the questioner.  As a debating technique, that's a useful 
approach, but it's not very helpful for developing a shared understanding of the 
issue.

Domain names are the Internet's universal identifier for organizations. That is, 
their administration and use aligns well with organizational boundaries. 
Operationally, they have demonstrated superb scaling properties.

Email addresses are the universal identifier for individuals and are based on 
domain names. (Even systems such as Facebook and LinkedIn, with their own 
namespace, are starting to support external identifiers, based on domain names, 
such as through OpenID.)

Choosing an organizational scope for anti-abuse identifiers turns out to make 
things dramatically more tractable operationally.  In addition, it seems to line 
up better in terms of distinguishing boundaries of trust and abuse.

Domain names have a rich OA&M base, which provides a very high point of 
departure for a new application, such as reputation work.  Lots of software, 
services and procedures can be re-used.

What have I missed?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "David F. Skoll" <[email-masked]>
Date: Tue, 13 Dec 2011 10:55:40 -0500

On Tue, 13 Dec 2011 07:33:24 -0800

> He's my own effort to prime the pump on the background for this

[... Excellent argument ...]

> Choosing an organizational scope for anti-abuse identifiers turns out
> to make things dramatically more tractable operationally.  In
> addition, it seems to line up better in terms of distinguishing
> boundaries of trust and abuse.

Thanks, that's what I was looking for.  But there's one thing about domain
names that makes them a problem: They are extremely cheap.  So what will
happen in practice is that domain names will end up being lumped into three
reputation classes:

1) A few very good reputation domains (paypal.com, ebay.com,
   big-bank.example.com, etc.) run by large institutions with a vested
   interest in keeping their reputations good and in using
   technologies like DKIM and SPF to reduce the chances of someone
   else successfully spoofing the domain.

2) A few neutral domains (hotmail.com, yahoo.com, gmail.com) that offer
   services to large numbers of users and can't really control what they do.

3) A vast population of domains with unknown reputations.

Now, (1) and (2) are certainly useful, but my feeling is that IP
address reputation will continue to be used extensively because it's
more expensive to obtain an IP address (even an IPv6 block) than a
domain and relatively expensive to change it frequently---you either
have to have money or a botnet.

Also, there's a danger that people will become suspicious of domains
in (3) and start penalizing small/unknown domains without a sound
basis for doing so.

Regards,

David.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 13 Dec 2011 08:46:55 -0800

On 12/13/2011 7:55 AM, David F. Skoll wrote:
>        But there's one thing about domain
> names that makes them a problem: They are extremely cheap.

Interesting point.  In effect, this particular downside is equivalent for domain 
names and IPv6 addresses, in that the namespace is so large a new name could 
plausibly be used with each new message.

>     big-bank.example.com, etc.) run by large institutions with a vested
...
> 3) A vast population of domains with unknown reputations.

This presumes that the mass of organizations who host their own mail -- or, 
rather, who send mail under their own domain name -- will not develop their own, 
stable reputation.

By way of example, I've sent mail under bbiw.net and dcrocker.net for 
considerably more than a decade.  I'd expect that to have established the 
reputations of the two domains quite solidly, one way or the other.  I don't 
know whether their are thousands or millions of equivalent domains, but I 
suspect my example applies to most such domains.

> have to have money or a botnet.

Predicting the future is always a challenge, since there are so many reasonable 
scenarios.  You are offering one; I think it's plausible but not necessarily 
correct.  At a minimum, the line of concern you are raising highlights the need 
for an effort like this to be extremely careful and clear to make the case for 
its value proposition over alternatives.

> in (3) and start penalizing small/unknown domains without a sound

You think the market of mail receivers might act emotionally?  Wow, that never 
happens...

d/

-- 

   Dave Crocker

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 13 Dec 2011 09:49:35 -0700

On 12/13/11 9:46 AM, Dave CROCKER wrote:
> Interesting point.  In effect, this particular downside is equivalent
> for domain names and IPv6 addresses, in that the namespace is so large a
> new name could plausibly be used with each new message.
> 
> 
> This presumes that the mass of organizations who host their own mail --
> or, rather, who send mail under their own domain name -- will not
> develop their own, stable reputation.
> 
> considerably more than a decade.  I'd expect that to have established
> the reputations of the two domains quite solidly, one way or the other. 
> I don't know whether their are thousands or millions of equivalent
> domains, but I suspect my example applies to most such domains.

Agreed. I don't understand why good reputations would adhere only to
large institutions.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Dec 2011 10:45:30 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of David F. Skoll
> Sent: Tuesday, December 13, 2011 7:56 AM
> To: [email-masked]
> Subject: Re: [domainrep] Appropriate choice of identity
> 
> Thanks, that's what I was looking for.  But there's one thing about
> domain names that makes them a problem: They are extremely cheap.  So
> what will happen in practice is that domain names will end up being
> lumped into three reputation classes:
> 

In my own experience building a DKIM-based reputation system, there are really only two categories:

1) ADMDs that develop and maintain good reputations

2) ADMDs for which one or more of these are true:
a) they don't sign their mail
b) I have little or no information about them
c) their behavior is middle-of-the-road (neutral reputation)
d) their behavior is historically undesirable (bad reputation)

Since as you point out domain names are cheap, attracting a negative reputation is trivially shed, so I don't go to any real lengths to treat a bad reputation differently than a neutral one (though if it's convenient or cheap to do so, I do), which is why that second group is so large.  Rather, I give sites that earn and preserve positive reputations more access to "me" (whatever that means in context) than everyone else.

It's not the case, though, that positive reputations are granted only to large institutions.  If you have a history of sending some signed mail and nobody complains about it, your reputation is positive, regardless of your size.

And ADMDs that fall in the second group aren't cut off entirety, but they get no preferential treatment and are lumped in with everyone else in that group in terms of how they are treated.  You have to distinguish yourself.

In my view, this creates a more meaningful economy: It is in your best interests to behave if you want access to my inboxes.  That means people will work hard to earn a good reputation, and work harder to keep it.  That promotes a sanitary ecosystem all around.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Dec 2011 10:48:44 -0800

Some of this thread, by the way, might be ideal fodder for our chartered "dos and don'ts of reputation" informational draft.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 13 Dec 2011 19:29:30 -0000

> [ they don't do that ]

I think the assumption has always been that as various sorts of domain
authentication become more widely used, people will be increasingly
sceptical of mail that doesn't have a good rep.

Also, it's pretty clear that IP addresses are going to be a lot harder
to use for reputation.  As IPv4 space runs out, you're going to see a
lot of NAT with multiple customers behing the same IP address,
particularly in Asia, and it'll be hard to have a single useful rep
for shared IPs.  Or they'll move to IPv6, where the addresses are
too cheap and it is, so far, impossible to tell how many bits of
an address you can attribute to a single customer.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Tue, 13 Dec 2011 11:34:05 -0800

On 12/13/11 7:33 AM, Dave CROCKER wrote:
> > Who decided that a domain name is an appropriate identity for
> > reputation with respect to email?
>
>
>  Unless I missed it, there does not seem to be a response to your
>  original question. The thread that ensued was perhaps interesting,
>  but I didn't see it answer this.
>
>  At the beginning of an activity like the Repute working group, it's
>  often useful to explore these sorts of foundational questions.
>
>  They can, of course, become distracting, but a bit of exploration by
>  the group might help folks develop a better, shared sense of what
>  motivates the group's work. Getting that into the mailing list
>  archive can also be helpful for other folks, later. (One can also
>  imagine the result of such a discussion helping to flesh out the
>  Introduction to a background or framework document, such as our own
>  -model.)
>
>  So... why a domain name?
>
>  In terms of the mechanics of fielding exemplar uses, both SPF and
>  Domainkeys (Yahoo!) are early examples of various folk deciding to
>  use domain names, with quite a bit of the anti-abuse technical
>  community lining up in support of that choice as time progressed. I
>  don't recall seeing any real controversy about the choice, within
>  that community.

The initial desire to include SPF was to mitigate spoofed DSNs.  DKIM 
was to mitigate phishing.  Neither ensures referenced domains were 
accountable for specific messages received.

SPF is equally problematic in conjunction with changing address 
topologies as would reputations directly based on the IP addresses that 
SPF attempts to authorize.  SPF also suffers from different intended 
uses.  Those who felt it could play a role against phishing referenced 
authorization from PRAs.  Unfortunately, the PRA or the MAIL-FROM are 
often invisible in phishing attempts.  When visible, it is not assured 
which message element referenced the SPF authorization and that this is 
also visible.  There is also the situation of shared resources, where 
senders may not ensure possible authorization references are solely 
allocated to that of the sender.  In most cases, no such allocation 
assurances are made.

As a result, SPF permits deceptive messages that might be used in 
conjunction with phishing.  In addition, those publishing SPF may be 
unable to defend against possible exploitation permitted by vague SPF 
references.  From a receiver resource perspective, SPF may demand 111 
subsequent transactions to convey all possible IPv4 and IPv6 addresses 
of the authorizing domain.  SPF's local-part macro capability allows 
receiver's resources to attack any otherwise uninvolved domain that may 
never be seen within any message with 300 to 1 network amplification 
while spamming.   A perfect two factor attack to evade detection and an 
ideal way to DDoS while spamming. :^(

DKIM is also problematic.  DKIM does not confirm intended recipients nor 
actual senders.  Company A invites those interested to subscribe to 
their newsletter.  Company B subscribes and replays Company A's 
newsletter using Bots sending to those who did not to injure company's A 
reputation.  Valid DKIM signatures also permit pre-pended header fields 
that can change the Subject or the From seen by recipients.  Such 
changes may deceive recipients or leverage acceptance based upon Company 
A's remaining and likely dwindling reputation.

For SPF or DKIM, defending reputation remains problematic.   The only 
exception will be for those considered "too big to block".  Basing 
acceptance on the combination of DKIM AND SPF would significantly reduce 
delivery integrity.  Basing acceptance on DKIM OR SPF would permit the 
exploitation of either SPF and DKIM's glaring weaknesses.

>  IP Addresses have been the dominant identifier in the anti-abuse
>  game. It is available at connection setup time and it has some
>  degree of validation, by virtue of being supplied out of band.
>  However there are some very serious drawbacks in the choice:
>
>  * Instability -- Since they are linked to network topology rather
>  than organizational boundaries; they typically belong to the
>  organization's service provider and not the organization, and they
>  get re-assigned.
>
>  * Ambiguity -- They often cover multiple users/organizations and
>  therefore create ambiguity in the reputation analysis.

Same would be true for any IP address authorization scheme, such as SPF.

>  * Obscurity -- IPv6 introduces an additional, looming nightmare for
>  use of IP Addresses as reputation identifiers; it massively increased
>  address space provides much greater opportunity for bad actors to
>  hide, by using new addresses at a high rate.

Same would be true for any IP address authorization scheme, such as SPF.

>  * Spoofing -- Although not common, IP Addresses can be spoofed.

DKIM and SPF are still more easily spoofed!

>  Now to the theoretical phase of the question, which goes something
>  like "so, why use domain names"?
>
>  A passive aggressive response is "what other choice is there, given
>  that IP Addresses are problematic?" It leaves the task of proposing
>  and promoting an alternative to the questioner. As a debating
>  technique, that's a useful approach, but it's not very helpful for
>  developing a shared understanding of the issue.
>
>  Domain names are the Internet's universal identifier for
>  organizations. That is, their administration and use aligns well with
>  organizational boundaries. Operationally, they have demonstrated
>  superb scaling properties.
>
>  Email addresses are the universal identifier for individuals and are
>  based on domain names. (Even systems such as Facebook and LinkedIn,
>  with their own namespace, are starting to support external
>  identifiers, based on domain names, such as through OpenID.)

The secure use of a domain with HTTP is normally done in conjunction 
with SSL certs and a CA, or perhaps a DANE RR.  There is no comparable 
session based mechanism available for email unless one were to consider 
S/MIME or Open PGP.  IMHO, a new SMTP Auth option could remedy this 
discrepancy.  And yes, that would then mean reputation would be based 
upon those acting to issue messages stewardship in excluding those who 
are abusive.

>  boundaries of trust and abuse.

Only when being held accountable for the actions, those who actually 
acted have been authenticated.  This is not the case for neither DKIM 
nor SPF.

>  Domain names have a rich OA&M base, which provides a very high point
>  of departure for a new application, such as reputation work. Lots of
>  software, services and procedures can be re-used.
>
>  What have I missed?

What it takes to impose a safe and fair reputation scheme that must 
include the principle of basing reputation only on authenticated actors.

The many avenues for exploitation are allowed by either DKIM or SPF can 
turn reputations into being highly disruptive.

-Doug