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=; mc=; mv=; where is the domain being vouched for, is the content type of the message, and is a list of domain names of certification providers that the sender asserts will vouch for this particular message. The structure of the 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 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]