Network Working Group P. Hoffman Internet-Draft J. Levine Expires: April 11, 2008 Domain Assurance Council A. Hathcock Alt-N Technologies October 9, 2007 Vouch By Reference draft-hoffman-dac-vbr-02.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 April 11, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Hoffman, et al. Expires April 11, 2008 [Page 1] Internet-Draft VBR October 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. Use 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 . . . . . . . . . . . . . . . . 11 7.1. DKIM . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. DomainKeys . . . . . . . . . . . . . . . . . . . . . . . . 11 7.3. SPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.4. Sender ID . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Informative References . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 16 B.1. Changes from 00 to 01 . . . . . . . . . . . . . . . . . . 16 B.2. Changes from 01 to 02 . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Hoffman, et al. Expires April 11, 2008 [Page 2] Internet-Draft VBR October 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 example.com" and/or "all mail from example.org". A prerequisite 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 April 11, 2008 [Page 3] Internet-Draft VBR October 2007 2. Use 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. The syntax of the header is defined in section 4. Hoffman, et al. Expires April 11, 2008 [Page 4] Internet-Draft VBR October 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 to determine whether the vouching service actually vouches for that type of content for that domain. Hoffman, et al. Expires April 11, 2008 [Page 5] Internet-Draft VBR October 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 April 11, 2008 [Page 6] Internet-Draft VBR October 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 a message signed by somebank.com contained the VBR- Info header above, the receiver might look up either or both 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 sent 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 April 11, 2008 [Page 7] Internet-Draft VBR October 2007 efficient, and certifiers can add and delete client records as quickly as they want. The lookup also leverages the DNS's negative caching ([RFC2308]). Hoffman, et al. Expires April 11, 2008 [Page 8] Internet-Draft VBR October 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. Note that the values in the mc= element is self-asserted. The purpose of this element is for auditing. There will likely be cases where a certifier will vouch for one type of a sender's mail (such as transactional mail) but not another type (such as advertising). A sender who cannot get get anyone to certify their advertising mail, but has a certifier for their transactional mail, might be tempted to cheat and mislabel it as transactional. The mc= element creates an the audit trail to help their certifiers catch such cheating and allow the removal of the certification for the transactional mail. 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 Hoffman, et al. Expires April 11, 2008 [Page 9] Internet-Draft VBR October 2007 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 April 11, 2008 [Page 10] Internet-Draft VBR October 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), [RFC4871], defines an accountable identity by associating a domain name with the message. 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 match the domain name taken from one of the DKIM-Signature header fields. If the DKIM signature contains an i= field, the domain name from that field is used; otherwise, the domain name from the DKIM signature d= field is used. o The VBR-Info header field should be included in the set of header fields protected by DKIM to prevent a malicious party from changing the contents of the VBR-Info header or adding bogus VBR- Info headers. o The 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 name taken from that signature is valid for use with VBR. 7.2. DomainKeys DomainKeys (DK), [RFC4870]. defines an accountable identity by associating a domain name with the message in the d= tag of the DomainKey-Signature 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 The VBR-Info header field should be included in the set of header fields protected by DK to prevent a malicious party from changing Hoffman, et al. Expires April 11, 2008 [Page 11] Internet-Draft VBR October 2007 the contents of the VBR-Info header or adding bogus VBR-Info headers. o The 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. 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 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 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 April 11, 2008 [Page 12] Internet-Draft VBR October 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 certifiers 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. Implementations should limit the number of VBR-Info headers they process in a single message in order to protect themselves from a make-work or denial-of-service attack. Hoffman, et al. Expires April 11, 2008 [Page 13] Internet-Draft VBR October 2007 9. Informative References [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. [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. [RFC4870] Delany, M., "Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, May 2007. [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. Hoffman, et al. Expires April 11, 2008 [Page 14] Internet-Draft VBR October 2007 Appendix A. Acknowledgements Many members of the Domain Assurance Council contributed to the design of the protocol and the wording of this document. In addition, constructive suggestions were received from Jim Fenton. Hoffman, et al. Expires April 11, 2008 [Page 15] Internet-Draft VBR October 2007 Appendix B. Change Log To be removed at time of publication B.1. Changes from 00 to 01 Added a reference to negative DNS caching from RFC 2308. Added a paragraph explaining that the mc= element is self-asserted and why that is so. Explained why the VBR-Info header should be signed in DKIM and DK. When using DKIM, changed the rule for domain name matching to: If the i= field is given, the domain name from that field is used; otherwise, the value of the d= field is used. Added a security consideration about limiting the number of VBR-Info headers a system should process. B.2. Changes from 01 to 02 Updated references to DK and DKIM for RFCs. Hoffman, et al. Expires April 11, 2008 [Page 16] Internet-Draft VBR October 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 April 11, 2008 [Page 17] Internet-Draft VBR October 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 April 11, 2008 [Page 18]