Subject: [Fwd: Last Call: draft-hoffman-dac-vbr (Vouch By Reference) to Proposed Standard]

From: Dave CROCKER <[email-masked]>
Date: Sun, 01 Feb 2009 11:40:24 -0800

>The IESG has received a request from an individual submitter to consider
>the following document:
>
>- 'Vouch By Reference'
>   <draft-hoffman-dac-vbr-04.txt> as a Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send substantive comments to the
>[email-masked] mailing lists by 2

This is being sent long-after the deadline for comments about Vouch by Reference 
(VBR), but several Discuss votes have been lodged and I am hoping this note 
provides input useful for resolving them.

Background
----------

As Internet mail has been subjected to increasing abuse, services have developed 
to assist email receiving operators in determining how likely it is that a given 
piece of email is safe to deliver.  One type of service evaluates content and 
makes heuristic assessments.  Another type uses a validated identifier that is 
associated with the message and assesses the owner of that identifier.  Modern 
email receiving software includes a Handling Filter module that juggles a 
potentially rich array of assessments and attributes, associated with the 
message, before deciding whether to deliver it.

Historically, the only validated identifier that was available was the IP 
Address of the last-hop sending SMTP engine. Although quite useful for this, an 
IP Address has a number of limitations for this application, particularly by 
virtue of being tied to network topology, rather than organizational boundaries. 
  To align better with the attributes of an organization, rather than the 
attributes of a network, domain names are generally considered a superior 
choice.  Hence there has been a range of efforts to associate a validated domain 
name with email, including SPF, Sender-ID, DomainKeys and the recent IETF 
Proposed Standard DKIM.

No matter how the domain name is obtained, its utility is not in the fact of 
being validated, but in serving as a basis for making an assessment of its owner.

As part of the DKIM working group, a Deployment document is under development 
and I've suggested it include the following diagram, primarily derived from a 
conversation with Mike Adkins, of AOL, when he noted that the module that comes 
after verification is the real target of DKIM.

We are finding that it greatly clarifies the systems view of the role of a 
validated identifier:

   +------+------+                            +------+------+
   |   Author    |                            |  Recipient  |
   +------+------+                            +------+------+
          |                                          ^
          |                                          |
          |                                   +------+------+
          |                                -->|  Handling   |<--
          |                                -->|   Filter    |<--
          |                                   +-------------+
          |                                          ^
          V                                          |
   +-------------+  Responsible Identifier    +------+------+
   | Responsible |...........................>|  Identity   |
   |  Identity   |                            |  Assessor   |
   +------+------+                            +-------------+
          |                                         ^ ^
          V        DKIM Service                     | | Query Service
+-----------------------------------------------+  | |
| +------+------+              +-------------+  |  | |  +-------------+
| | Identifier  |              |  Identifier +--|--+ +--+ Assessment  |
| |   Signer    +------------->|  Validator  |  |       | Databases   |
| +-------------+              +-------------+  |       +-------------+
+-----------------------------------------------+

Although tailored for DKIM, the gist of this diagram is independent of the means 
by which the domain name is obtained and verified.

At base it notes that the goal is for the owner of a domain name to have the 
name used by a receive-side assessment module, such as for determining the 
reputation the owner has as a Good Actor.

Once the use of such a domain name that is has been validated, there needs to be 
some means of using it to assess its owner. This tasked is marked as "Query 
Service" in the diagram.

This is the need that Vouch by Reference (VBR) satisfies.

Since a validated domain name is useless without the assessment step, 
standardizing a mechanism for querying assessment information is a natural and 
necessary activity, in developing common Internet capabilities for 
distinguishing legitimate email from abusive email.

VBR History
-----------

VBR was developed by an ad hoc industry consortium, primarily comprising 
independent services offering reputation analysis of email senders.  That is, 
competitors collaborated to define a common mechanism.  Seven companies formed 
the core, with assistance from a few more. See:

    <http://www.domain-assurance.org/member-list.phtml>

The specification underwent a number of design revisions, in response to the 
usual proposal/debate/negotiation sequence.  Although the impetus for VBR was 
DKIM's standardization, one revision to the specification made it be entirely 
independent of DKIM, so that it can be equally useful for domain names that are 
validated by other means.  The goal was a simple, narrow mechanism designed to 
fit efficiently and safely within the DNS infrastructure, and providing a 
common, simple core that can be extended as experience is gained. By all 
accounts, that goal was achieved.

Reviews of the design have been favorable and there has been some early 
implementation.

As an example of its general utility, I have recently been exploring community 
interest in an assessment service based on affiliation ("membership") in a 
group, rather than in having a good reputation.  For example, being listed by 
the FDIC as a member bank.  The expectation is that such affiliation lists will 
provide useful input to Handling Filters.  Although still in an early stage of 
development, this work has been greatly aided by being able adopt VBR as its 
query mechanism, rather than having to design a new one:

    <http://mipassoc.org/affil>

VBR Design
----------

VBR is a query service that operates over the DNS, providing assessment 
information about a domain name, via a third-party service.

The third party service populates a DNS branch owned by the third party, with 
the remainder of a sub-domain name being defined as a domain name that is 
associated with the email message.  This is a common model for query services 
that are layered on top of the DNS.  The model is extremely mature, in terms of 
years of experience and scalability of use:

    <associated domain name>.<third-party service domain name>

Specific conventions tailor this model for specific services, using refinements 
to the model that have become standard.  In the case of VBR, the model has the 
name be:

    <associated domain name>._vouch.<third-party service name>

Assessment data are encoded in TXT RRs.

So, a message containing a validated example.org domain name might produce a 
query to the assessment service run by example.com, with the combined lookup 
name of:

    example.org._vouch.assessment.example.com

For convenience and efficiency, VBR permits the owner of the <associated domain 
name> to supply hints to a potential querier, by adding a VBR-Info: header field 
to the message.  In particular, a hint can indicate which service(s) that the 
receiver should query.  Whether that service is queried depends upon whether the 
receiver already has a basis for trusting it and whether the receivers deems it 
appropriate to query for this message.

IESG Concerns
-------------

Based on the Discusses that have been lodged (including those resolved) concerns 
focus on:

      1.  Macroeconomic effect from email filtering:  Monopolistic pressures

>    implications
> to individual or small companies, particularly ones in small emerging market
> countries, are likely going to have a very hard time getting any widely
> accepted  assurance group to vouch for them
...
> IESG should be
> trying to decide if there is consensus for this and right now

Successful operation of Internet mail already relies on the use of assessment 
mechanisms.  This has been true for perhaps a decade, with the current industry 
use of such mechanisms being essentially 100%.  (Yup.  Within a reasonable 
statistical error limit, absolutely every professional operation of email uses 
filters that decide whether a message can be trusted.) The vast majority of 
these include queries to databases that rate the reputation of an identity 
associated with the message.

Given that more than 90% of email over the open Internet is spam -- with many 
estimates reaching 98%! -- this reliance on mechanisms to evaluate the likely 
safety of messages should not be surprising.

VBR does not change this reliance.  Nor does it change the model.  It merely 
standardizes a component mechanism that uses a newer form of identifier. In 
other words, VBR blazes no new conceptual trails; it merely takes a proven model 
and applies it to a newer type of identifier in a manner that conforms to the 
needs and style of the DNS.

Whatever effects such mechanisms might have on the "market" of global email 
service, they have been underway for quite a few years and IETF standardization 
of VBR will not affect them.  Rather, IETF standardization will merely do what 
technical standards are supposed to do:  improve the quality and reduce the cost 
of a component mechanism.

As an aside, I'll note that the stated likelihood is almost certainly wrong. 
Given how completely the industry already relies on assessment mechanisms, if 
the prediction were going to be true, it already ought to be.  However I am not 
aware of any documentation of this trend, nor of any pattern of complaints that 
it is true. On the other hand, it is certainly true that *all* senders of email 
now have to work more diligently to get their mail delivered, than they did 10 
years ago.  Hence, email deliverability certainly has become a technical and 
operations specialty, as has other Internet services, such as routing and web 
operations.

      2.  DNS

> DNS-Directorate review issues need a complete answer

I cannot find any documentation or discussion of this review or the issues it 
raises.

Making some guesses:

Since VBR employs a model that has been used repeatedly, such as for SRV and 
DKIM, the mechanical details of the VBR design ought not to be a concern with 
respect to DNS operation.

Because VBR participates in a service that can reasonably be classed under 
"security", it should raise the same questions about DNS vulnerability that have 
been raised for other uses under that umbrella.  I am not aware of anything in 
the VBR design that changes the existing DNS security issues, so I am hoping 
that it merely adds fuel to the effort at making protection of the DNS 
infrastructure stronger.

      3.  Target market

> Who will implement it and who will deploy it?

Email senders and receivers currently engage in various forms of "negotiation" 
to get mail delivered. Some senders are Good Actors, trying to conform to 
different receivers' rules for acceptable mail traffic and content, and others 
are Bad Actors seeking to game the receivers.  The negotiation is often both 
indirect and mediated, by third-party services.

Anyone operating an outbound or inbound email border MTA is typically a 
candidate for using one or more assessment mechanisms.  As noted above, this is 
already 100% of the professional email operations market.  All of that market 
currently relies on IP Addresses for identification, but industry movement 
towards using domain names is progressing nicely.  Everyone who uses domain 
names for identification can be expected to need a mechanism like VBR.

Consequently, implementation is expected to be by all major developers of email 
sending and receiving software.  It is equally expected that it will be deployed 
by 100% of the community providing professional email operations, both on the 
sending and the receiving sides.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: SM <[email-masked]>
Date: Tue, 03 Feb 2009 10:09:36 -0800

At 11:40 01-02-2009, Dave CROCKER wrote:
>Based on the Discusses that have been lodged (including those 
>resolved) concerns focus on:
>
>

There wasn't any comments on the Last-Call about the implications to 
individual or small companies, particularly ones in small emerging 
market countries.  It's refreshing to see such a question being 
brought up during an IESG evaluation.

Does the IETF community believe that the following text (see IESG 
Evaluation) is appropriate:

  "If a recipient selects one or more vouch-for domains, and uses the
   results of vouching to adjust spam scores on incoming email, that
   recipient is placing a great deal of operational trust and power
   in the selected vouch-for service operators.  Recipients are strongly
   encouraged to select such services with care.  Further, recipients
   are strongly encouraged to select more than one vouch-for service to
   avoid a single-point-of-failure and to avoid placing excessive trust
   and power in a single vouch-for service operator."
What about senders from small emerging market countries having a very 
hard time getting any widely accepted assurance group to vouch for them?

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 04 Feb 2009 15:23:36 +0100

> hard time getting any widely accepted assurance group to vouch for them?

Also in more mature markets, not all of the existing companies and 
universities running their own mail servers will be eager to spend 
$5000/year on a vouch. In addition, the semantics of vouching is even 
less specified than mc types. What kind of checks would a vouch-for 
service operator carry out? I hope it will not be something similar to 
getting a server TLS certificate... Will organizations like, say, 
spamhaus.org issue _vouch records for free?

Dave CROCKER wrote:
> Modern email receiving software includes a Handling Filter module that juggles a potentially rich array of assessments and attributes, associated with the message, before deciding whether to deliver it.

While that describes current practices correctly, it is at odds with 
the concept of reliable mail transmission that the SMTP model (5321) 
describes. In facts, mail sent to (some) giant ESPs may pass unnoticed 
through recipients' mailboxes, if the sender didn't take care to 
ensure deliverability by some obscure ESP-specific procedure. VBR 
makes that behavior explicit. However, it provides no means to find 
out which vouch-for operators a given recipient trusts, except by 
manually searching in a giant ESP's web site for policies or 
statements referring that.

The "obvious solution" for those 2nd class senders is to use one of 
the giant ESPs as a submission agent, so as to delegate the handling 
of outgoing email to a transmitter with plenty of clout. This 
distinction between 1st class senders and smaller MTAs might remind 
the ADMD/PRMD classification. We may be better off providing a 
protocol method for verifying in advance what is going to happen with 
a given message. For example,

   C:  VHLO example.com VBR:mv=operator1:operator2:operator3
   S:  551 we only accept VBR:mv=operatorA:operatorB:operatorC

   lets the client know that its mail is not going to be delivered in 
the recipient's primary folder. That way, a client can be configured 
to attempt regular MX delivery first, and resort to its preferred 
giant MSA only if necessary. (Who'd write such extension? Please, send 
any specific follow-up to a more specific list.)

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 04 Feb 2009 06:55:48 -0800

SM wrote:
> market countries.  It's refreshing to see such a question being brought 
> up during an IESG evaluation.

Good that we care?  Sure.  Good that we base formal approval on it?  Maybe not.

Macroeconomic analysis -- especially predictions about the directions an 
economic process will develop towards -- is a poorly understood topic of 
expertise, even among experts... as we are unfortunately seeing demonstrated in 
the global economy.

What is the IETF track record that should give us any faith in this community's 
ability to make such predictions.  Absent that track record, we are creating the 
risk that we will refuse technologies erroneously.

The IETF defines technologies, not markets.

d/

---

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 4 Feb 2009 20:12:58 -0000

>$5000/year on a vouch.

Sheesh.  The point of having a standard is to make it easy to
interoperate.  That means that anyone who wants to set up a VBR
vouching service can do so, and anyone who wants to use your vouching
service can also do so by adding a line to a config file.  I certainly
have no intention of paying anyone $5000 to get mail from my tiny
system delivered.

Like Dave, I don't see any reason to expect one economic model or
another to predominate, and no reason at all to expect there to be
only a small oligoply set of providers.  Although I think that VBR is
a swell idea, it also seems rather a stretch to expect that it would
ever become so popular that you couldn't get mail delivered without
it.

In the near term, the most likely usage I see is for phish resistance.
If organizations like the FDIC were to publish a VBR list of the
domains of their genuine member banks, that would make it easier to
have a mail system put a flag on suitable signed incoming mail to say
"this is really from a bank."

R's,
John

---

From: SM <[email-masked]>
Date: Fri, 06 Feb 2009 00:32:07 -0800

At 06:23 04-02-2009, Alessandro Vesely wrote:
>$5000/year on a vouch. In addition, the

The cost for email certification starts at around $1200 (950 Euros) a year.

At 06:55 04-02-2009, Dave CROCKER wrote:
>Macroeconomic analysis -- especially predictions about the 
>directions an economic process will develop towards -- is a poorly 
>understood topic of expertise, even among experts... as we are 
>unfortunately seeing demonstrated in the global economy.

One of the characteristics of Internet Mail is it doesn't require 
prior arrangement between senders and receivers.  If email 
certification is widespread, it can have an impact on the model.

>What is the IETF track record that should give us any faith in this 
>community's ability to make such predictions.  Absent that track 
>record, we are creating the risk that we will refuse technologies erroneously.

That's where operational experience come into play.  It's easier to 
assess a technology based on that.  A specification sometimes contain 
guidance about the technology, for example, a note about trusting 
third parties with operational decisions.

If the technology is deployed by 100% of the community providing 
professional email operations, both on the sending and the receiving 
sides, as Dave expects, the rest of the world can either follow the 
practice or else bear the consequences.  As the IETF community does 
not have any track record on its ability to make economic 
predictions, should it restrict itself to a assessment of a 
technology without looking at whether the benefits outweigh the costs 
which may only affect a fringe of the Internet community?  The cost 
of deployment has been taken into consideration in the design of some 
specifications published on the Standards Track.

Regards,
-sm

---

From: John Levine <[email-masked]>
Date: 6 Feb 2009 10:47:53 -0000

>sides, as Dave expects, ...

I'm not Dave, but I cannot imagine where you got the idea that he
expects the "community providing professional email operation" to
deploy 100% of anything.

The idea that big mail systems will form a cartel and lock out people
who won't pay is just silly to anyone who remembers the history of
e-mail.  There used to be lots of closed commercial email systems,
including AOL, Compuserve, and MCI Mail where Dave worked.  Without
exception, they all were swept away by Internet mail which was cheap,
universal, and unmetered, even though in some ways it was technically
inferior to those systems.  Some of them, like AOL, morphed into ISPs,
others like MCI Mail just died.

If some group wanted to build a closed pay-to-play mail system, they
could do it with the tools they already have, using SMTP AUTH or
STARTTLS with a private signing cert or VPNs or whatever.  The reason
they don't is that it makes no sense, and a tiny tweak like VBR isn't
going to change that.

Is there any possibility that you are confusing threats that are easy
to imagine with threats that are likely?  Because this one isn't likely.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 06 Feb 2009 05:05:50 -0800

SM wrote:
>> Macroeconomic analysis -- especially predictions about the directions 
>> an economic process will develop towards -- is a poorly understood 
>> topic of expertise, even among experts... as we are unfortunately 
>> seeing demonstrated in the global economy.
> 
> One of the characteristics of Internet Mail is it doesn't require prior 
> arrangement between senders and receivers.  If email certification is 
> widespread, it can have an impact on the model.

Adding a small technical correction, since John L's response covers the rest:

"without prior arrangement" is a phrase that is used about most Internet 
protocols.  It refers to prior arrangement *between the two participants*.

All sorts of other arrangements are common, for using the Internet, such as 
getting an IP Address and a domain name.

Nothing about VBR encourages a change in being able to send mail between two 
parties without prior arrangement... between those two parties.

d/
-- 

   Dave Crocker

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 06 Feb 2009 16:24:44 +0100

> they don't is that it makes no sense, and a tiny tweak like VBR isn't

I didn't imply that any of the big 4 wants their users to pay for an 
email account. However, they are defining a mail system, which is 
possibly slightly different from the IETF definition, and flags spam 
abatement as a major advantage. Very roughly, that system is around 
one half of the total existing mailboxes[1]. That is to say, any one 
of the big 4 can expand its share better by acquiring users from minor 
MTAs than from direct competitors. This is not the same as a full 
blown cartel, but it tends to relegate minor MTAs to 2nd class.

The other thing I don't understand is why you minimize the expected 
VBR effect. (If that's meant as an apotropaic stance, I have no 
objection. Otherwise,) I wonder why we shouldn't push VBR as hard as 
we can, if it can stop spam.

Finally, I'd remark that, IMHO, such considerations are exactly what 
the IETF is for: not inventing mere rocket techniques, but do internet 
technology in its broadest meaning, including any economic, social, or 
political facet that may be relevant for the task.

--
[1]
Microsoft webmail properties: 256.2 million users
Yahoo: 254.6 million users
Google: 91.6 million users
AOL webmail properties: 48.9 million users
http://www.email-marketing-reports.com/metrics/email-statistics.htm

Internet users: 1,018,057,389 (2005)
https://www.cia.gov/library/publications/the-world-factbook/geos/xx.html#Comm

---

From: "John R. Levine" <[email-masked]>
Date: Fri, 6 Feb 2009 15:50:58 +0000 (GMT)

> The other thing I don't understand is why you minimize the expected VBR 
> effect. (If that's meant as an apotropaic stance, I have no objection. 
> Otherwise,) I wonder why we shouldn't push VBR as hard as we can, if it can 
> stop spam.

Could you point out where anyone, anywhere has claimed that VBR would 
"stop spam"?  It's a technology to whitelist mail from people you trust.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 06 Feb 2009 08:04:52 -0800

Alessandro Vesely wrote:
> effect. 

What I don't understand is your certitude about specific impact.

There is a considerable difference between having a large effect -- which is 
what any proponent of an IETF standard hopes for -- versus having a *particular* 
impact.

Anyone who is certain of the second- and third- and fourth- order effects of 
adopting a particular protocol is ignoring the pattern of surprise that 
accompanies real-world developments for anything with a social component.

The reality of VBR is that it is almost entirely subject to social forces.

d/
-- 

   Dave Crocker

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 06 Feb 2009 17:22:54 +0100

> "stop spam"?  It's a technology to whitelist mail from people you trust.

...I trust as not being spammers, you mean. Isn't that the same thing?

Self-referencing DNS based techniques are out there already, and have 
been criticized claiming that it is actually easier for spammers to 
comply than it is for legitimate users. Hence a third party is 
required. Reverse DNS and whois databases unfortunately are not apt. 
Ergo, VBR.

> What I don't understand is your certitude about specific impact.

It's not certitude, it's hope. OTOH, do we have anything better? 
(We're not allowed to use nuclear weapons, are we ;-))

> Anyone who is certain of the second- and third- and fourth- order effects of adopting a particular protocol is ignoring the pattern of surprise that accompanies real-world developments for anything with a social component.
> 

Strongly agreed! It will only work if all the people will like it, and 
agree on a restricted set of vouch-for operators, and use it. Likely?

--
         Imagine all the people
         Sharing all the world
         You may say I'm a dreamer
         But I'm not the only one

John Lennon, 1971

---

From: SM <[email-masked]>
Date: Fri, 06 Feb 2009 10:18:45 -0800

>expects the "community providing professional email operation" to

I'll quote the last part of the message from Dave ( 
http://www.ietf.org/mail-archive/web/ietf/current/msg55204.html ) 
about who will implement VBR and who will deploy it:

   "Anyone operating an outbound or inbound email border MTA is 
typically a candidate for using one or more assessment 
mechanisms.  As noted above, this is already 100% of the professional 
email operations market.  All of that market currently relies on IP 
Addresses for identification, but industry movement towards using 
domain names is progressing nicely.  Everyone who uses domain names 
for identification can be expected to need a mechanism like VBR.

Consequently, implementation is expected to be by all major 
developers of email sending and receiving software.  It is equally 
expected that it will be deployed by 100% of the community providing 
professional email operations, both on the sending and the receiving sides."

>others like MCI Mail just died.

I am not aware of any consortium of independent organizations 
providing mail services formed to limit competition or to lock out 
people who won't pay.  I did not equate the "community providing 
professional email operation" with big mail systems or infer that 
they will form a cartel.

>to imagine with threats that are likely?  Because this one isn't likely.

The gist of my comments was about the impact of your proposed 
specification if the technology is widely deployed.  My opinion is 
based on operational experience and not on market theories.

Regards,
-sm