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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
ietf@xxxxxxxx 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]