DKIM Deployment

[Lucy Lynch <>]

All -

Just FYI...


Lucy Lynch
Director of Technical Projects
Internet Society (ISOC)


---------- Forwarded message ----------
Date: Sun, 01 Feb 2009 11:40:24 -0800
From: Dave CROCKER 
<>
Reply-To: 

To: IETF Discussion 
<>,
 iesg 
<>
Subject: [Fwd: Last Call: draft-hoffman-dac-vbr (Vouch By Reference) to 
Proposed
     Standard]

> 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
>
>  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

https://www.ietf.org/mailman/listinfo/ietf