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