Network Working Group P. Hoffman
Internet-Draft J. Levine
Expires: August 27, 2007 Domain Assurance Council
A. Hathcock
Alt-N Technologies
February 23, 2007
Vouch By Reference
draft-hoffman-dac-vbr-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 27, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Hoffman, et al. Expires August 27, 2007 [Page 1]
Internet-Draft VBR February 2007
Abstract
This document describes the Vouch By Reference (VBR) protocol. VBR
is a protocol for adding third-party certification to email. It
permits independent third parties to certify the owner of a domain
name that is associated with received mail.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Format of the VBR-Info Header . . . . . . . . . . . . . . . . 4
3. Validation Process . . . . . . . . . . . . . . . . . . . . . . 5
4. The VBR-Info Header . . . . . . . . . . . . . . . . . . . . . 6
5. DNS Query . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Types of Message Content . . . . . . . . . . . . . . . . . . . 9
6.1. All . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. List . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Transaction . . . . . . . . . . . . . . . . . . . . . . . 9
6.4. Vendor-specific types . . . . . . . . . . . . . . . . . . 9
7. Obtaining a Useful Domain Name . . . . . . . . . . . . . . . . 10
7.1. DKIM . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. DomainKeys . . . . . . . . . . . . . . . . . . . . . . . . 10
7.3. SPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.4. Sender ID . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Informative References . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Hoffman, et al. Expires August 27, 2007 [Page 2]
Internet-Draft VBR February 2007
1. Introduction
Vouch By Reference, or VBR, is a protocol for adding third-party
certification to email.
Specifically, VBR permits independent third parties to certify the
owner of a domain name that is associated with received mail. VBR
may be performed anywhere along the email transit path, by any
capable receiving module, either within the handling service or by
end-user software.
VBR accomplishes this with a two-part protocol:
o In the first part, a sender affixes VBR information to email
messages. The VBR information says which domain certification
services the sender believes will vouch for email traffic
associated with that sender.
o In the second part, the receiver queries one or more certification
services to obtain information about the identity that has been
associated with a received message. This latter protocol uses the
DNS to distribute the certification information.
A sender provides certification attestations through the use of a new
RFC 2822 [RFC2822] mail header field, "VBR-Info:". This header field
contains the names of services that the sender claims will vouch for
them, and the particular type of content of the message. A queried,
third-party, DNS-based certification service can respond with a list
of the types of message content they will vouch for, such as
"transactional mail from example1.com" and/or "all mail from
example2.com".
A basic requirement for successful VBR operation is validation of the
identity associated with the message. VBR is based on the use of
domain names as identifiers, and permits multiple methods of
obtaining and validating domain names. The validation methods are
described in the "Obtaining a useful domain name" section below.
The sender performs two steps:
1. Adds a VBR-Info header field to its message
2. Protects the message, as appropriate
[[ The intended status of this document is an Informational RFC that
will be submitted as an independent submission to the RFC Editor. ]]
Hoffman, et al. Expires August 27, 2007 [Page 3]
Internet-Draft VBR February 2007
2. Format of the VBR-Info Header
A sender uses VBR to say which domain certification services the
sender believes will vouch for a particular piece of mail. The
certification service uses VBR to state which signatures it will
vouch for. This protocol uses the DNS to distribute the
certification information.
A message may have multiple VBR-Info header fields. This means that
in 2822 terminology, VBR-Info is a "trace header field" and should be
added at the top of the header fields.
The content of the VBR-Info header is a list of three elements:
o The accountable domain
o The type of content in the message
o A list of domain names of services that the sender expects to
vouch for the sender for that kind of content
The accountable domain is given as md= followed by a domain name.
The content type is given as mc= followed by a string; the defined
values of that string are found below. The list of services is given
as mv= followed by a colon-separated list of domain names.
Hoffman, et al. Expires August 27, 2007 [Page 4]
Internet-Draft VBR February 2007
3. Validation Process
A message receiver uses VBR to determine certification status by
following these steps:
1. Extracts the domain to certify and the type of message content
2. Verifies legitimate use of that domain using one or more
authentication mechanisms as described herein
3. Obtains the name of a vouching service that it trusts, either
from among the set supplied by the sender or from another source
4. Queries the vouching service about whether the vouching service
actually vouches for that type of content for that domain.
Hoffman, et al. Expires August 27, 2007 [Page 5]
Internet-Draft VBR February 2007
4. The VBR-Info Header
The VBR-Info header has the following format:
VBR-Info: md=<domain>; mc=<type-string>; mv=<certifier-list>;
where <domain> is the domain being vouched for, <type-string> is the
content type of the message, and <certifier-list> is a list of domain
names of certification providers that the sender asserts will vouch
for this particular message. The structure of the <certifier-list>
is one or more domain names, with a colon (":") between each.
For example, assume that the signer has two companies who are willing
to vouch for its transactional notices: certifier-a.com and
certifier-b.com. The signer would add the following to the header of
its outgoing message.
VBR-Info: md=somebank.com; mc=transaction;
mv=certifier-a.com:certifier-b.com;
All three fields in the VBR-Info header are mandatory. In
particular, there is no default for the md= domain.
Upper and lower case characters in a VBR-Info header are equivalent,
although conventionally the fields are all in lower case. For upward
compatibility, verifiers should accept the fields in any order and
should ignore any fields other than the three defined here.
If a message has more than one VBR-Info header, verifiers should
check each in turn or in parallel until either a satisfactory
certifier is found or all the headers have been checked. All of the
VBR-Info headers in a single message should have identical mc=
values. The semantics of a message with non-identical mc= categories
are undefined.
Hoffman, et al. Expires August 27, 2007 [Page 6]
Internet-Draft VBR February 2007
5. DNS Query
When a recipient wants to check whether a message is vouched for, it
compares the list in the message to the list of services it trusts.
For each service that is on the intersection of the two lists, it
creates a domain name to look up that consists of the following DNS
labels (from left to right):
o the domain name which asserts it can be certified
o _vouch (a string literal)
o the host name of the vouching service
This domain name is queried for a DNS TXT record.
For example, if the mail was signed by somebank.com, the receiver
might look up either of the following names, depending on which
vouching service it trusts:
somebank.com._vouch.certifier-b.com
somebank.com._vouch.certifier-a.com
If the DNS TXT record exists, it contains a space-delimited list of
all the types that the service certifies. For example, the contents
of the TXT record might be:
transaction list
In the example above, the receiver checks whether or not either
certifier vouches for "transaction" mail. That would be indicated by
either of the following types: "all" or "transaction" ("all"
indicates that the certifier vouches for all message types send by
the domain in question). If either of those types appear in either
TXT record, the message is vouched for. Of course, the recipient
must ignore services that it does not trust; otherwise, a bad actor
could just add an authority that it has set up so that it can vouch
for itself.
The name for the label _vouch was chosen because any domain name that
includes it as one of its labels cannot be a valid host name. There
will never be any accidental overlap with a valid domain name.
Further, it is safe to create a rule that says that a TXT DNS record
that comes from a domain name that includes a _vouch label will
always have the structure defined in this document.
This query method relies on the considerable advantages of existing
DNS efficiencies, reliability and experience. The lookup is very
Hoffman, et al. Expires August 27, 2007 [Page 7]
Internet-Draft VBR February 2007
efficient, and certifiers can add and delete client records as
quickly as they want.
Hoffman, et al. Expires August 27, 2007 [Page 8]
Internet-Draft VBR February 2007
6. Types of Message Content
This section describes the types of content that can be vouched for.
While the rest of the VBR specification is mostly technical and
precise, describing the types of contents in mail messages is
inherently open to interpretation. Thus, this section makes
distinctions in as specific a way as possible, but the reader must
understand that these semantic definitions can be interpreted in very
different ways by different people.
Currently, three types of content are defined. The Domain Assurance
Council (DAC) may add additional types in the future, including
adding vendor-specific types. DAC controls the names used in the VBR
specification.
6.1. All
"all" means all mail from the sender.
6.2. List
"list" is the category for email sent to multiple recipients where
each piece of mail is identical or is very similar to the others.
6.3. Transaction
"transaction" is the category for transactional messages. This is a
response to a specific action of the user's, or a notice about an
event in the user's account at the sender.
6.4. Vendor-specific types
Members of the Domain Assurance Council (DAC) can also create their
own vendor-specific types with their own semantics. Members define
their own semantics for their own types.
DAC expects that most mail will use the standard types of categories,
but that some systems will use the vendor-specific types for
particular mail between known parties. Recipients who do not care
about the vendor-specific categories can just use the generic types,
while recipients who want to use the vendor-specific types can do so
as well.
The list of assigned vendor-specific types will be listed on the DAC
membership list as they are assigned.
Hoffman, et al. Expires August 27, 2007 [Page 9]
Internet-Draft VBR February 2007
7. Obtaining a Useful Domain Name
VBR relies on having a domain name that specifies "a party that is
accountable for the message." This requires obtaining the domain
name and possessing a strong basis for believing that the use of the
domain name is valid, that is, that it has not been spoofed.
There are different ways to achieve this and this section discusses
the allowed mechanisms.
7.1. DKIM
DomainKeys Identified Mail (DKIM), [DKIM], defines an accountable
identity by associating a domain name with the message in the d= tag
of the DKIM-Signature header. It provides assurance that the
association is valid through a public-key-based authentication
mechanism.
o When DKIM is the validation mechanism, VBR's md= must be same
value as the d= in one of the DKIM-Signature header fields.
o The VBR-Info header field should be included in the set of header
fields protected by DKIM.
o This VBR-Info header field should be added at the header
immediately below the corresponding DKIM-Signature header field.
If the DKIM signature validates, the domain in the d= tag is valid
for use with VBR.
7.2. DomainKeys
DomainKeys (DK), [DK]. defines an accountable identity by associating
a domain name with the message in the d= tag of the DomainKey-
Signature header. header field. It provides assurance that the
association is valid through a public-key-based authentication
mechanism.
o When DomainKeys is the validation mechanism, VBR's md= must be the
same value as the domain name found in the DomainKey-Signature d=
parameter.
o This VBR-Info header field should be added immediately below the
corresponding DomainKey-Signature header field.
If the DomainKeys signature validates, the domain in the d= tag is
valid for use with VBR.
Hoffman, et al. Expires August 27, 2007 [Page 10]
Internet-Draft VBR February 2007
7.3. SPF
Sender Policy Framework (SPF), [RFC4408], defines an accountable
identity by using an existing message address and querying the DNS to
discover whether it is valid for SPF use.
When SPF is the validation mechanism, VBR's md= must be the same
value as the the domain name in the <reverse-path> address that is in
the SMTP MAIL command.
A domain is valid for use with VBR when the SPF process produces a
"pass" result, but not when it produces a "neutral", "none",
"softfail", or other result.
7.4. Sender ID
Sender ID, [RFC4406], defines an accountable identity by using an
existing message address known as the Purported Responsible Address
and querying the DNS to discover whether it is valid for Sender ID
use.
When Sender ID is the validation mechanism, VBR's md= must be the
same value as the the domain name in the Purported Responsible
Address in the message.
A domain is valid for use with VBR when the Sender ID process
produces a "pass" result, but not when it produces a "neutral",
"none", "softfail", or other result.
Hoffman, et al. Expires August 27, 2007 [Page 11]
Internet-Draft VBR February 2007
8. Security Considerations
VBR is used to allow users to trust independent third parties to
certify the owner of a domain name that is associated with received
mail. The party validating the mail might use that trust
relationship to perform actions that affect the security of their
system.
The receiver of a message with a VBR-Info header must ignore services
that it does not trust; otherwise, a bad actor could just add an
authority that it has set up so that it can vouch for itself.
Hoffman, et al. Expires August 27, 2007 [Page 12]
Internet-Draft VBR February 2007
9. Informative References
[DK] "Domain-based Email Authentication Using Public Keys
Advertised in the DNS (DomainKeys)",
draft-delany-domainkeys-base (work in progress).
[DKIM] "DomainKeys Identified Mail (DKIM) Signatures",
draft-ietf-dkim-base (work in progress).
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail",
RFC 4406, April 2006.
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, Version 1",
RFC 4408, April 2006.
Hoffman, et al. Expires August 27, 2007 [Page 13]
Internet-Draft VBR February 2007
Appendix A. Acknowledgements
Many members of the Domain Assurance Council contributed to the
design of the protocol and the wording of this document.
Hoffman, et al. Expires August 27, 2007 [Page 14]
Internet-Draft VBR February 2007
Authors' Addresses
Paul Hoffman
Domain Assurance Council
Email: paul.hoffman@domain-assurance.org
John Levine
Domain Assurance Council
Email: john.levine@domain-assurance.org
Arvel Hathcock
Alt-N Technologies
Email: arvel.hathcock@altn.com
Hoffman, et al. Expires August 27, 2007 [Page 15]
Internet-Draft VBR February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Hoffman, et al. Expires August 27, 2007 [Page 16]
