Network Working Group                                         P. Hoffman
Internet-Draft                                                 J. Levine
Intended status: Standards Track                Domain Assurance Council
Expires: April 12, 2009                                      A. Hathcock
                                                      Alt-N Technologies
                                                         October 9, 2008


                           Vouch By Reference
                      draft-hoffman-dac-vbr-04.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 12, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

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.





Hoffman, et al.          Expires April 12, 2009                 [Page 1]

Internet-Draft                     VBR                      October 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Use of the VBR-Info Header . . . . . . . . . . . . . . . . . .  4
   3.  Validation Process . . . . . . . . . . . . . . . . . . . . . .  4
   4.  The VBR-Info Header  . . . . . . . . . . . . . . . . . . . . .  4
   5.  DNS Query  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   6.  Types of Message Content . . . . . . . . . . . . . . . . . . .  6
     6.1.  All  . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     6.2.  List . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     6.3.  Transaction  . . . . . . . . . . . . . . . . . . . . . . .  7
   7.  Obtaining a Useful Domain Name . . . . . . . . . . . . . . . .  7
     7.1.  DKIM . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     7.2.  DomainKeys . . . . . . . . . . . . . . . . . . . . . . . .  8
     7.3.  SPF  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     7.4.  Sender ID  . . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  Normatives References  . . . . . . . . . . . . . . . . . .  9
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 10
   Appendix B.  Change Log  . . . . . . . . . . . . . . . . . . . . . 10
     B.1.  Changes from 00 to 01  . . . . . . . . . . . . . . . . . . 10
     B.2.  Changes from 01 to 02  . . . . . . . . . . . . . . . . . . 11
     B.3.  Changes from 02 to 03  . . . . . . . . . . . . . . . . . . 11
     B.4.  Changes from 03 to 04  . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
   Intellectual Property and Copyright Statements . . . . . . . . . . 12























Hoffman, et al.          Expires April 12, 2009                 [Page 2]

Internet-Draft                     VBR                      October 2008


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 5322 [RFC5322] 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 somebank.example" and/or "all mail from
   anotherbank.example".

   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 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].






Hoffman, et al.          Expires April 12, 2009                 [Page 3]

Internet-Draft                     VBR                      October 2008


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


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.


4.  The VBR-Info Header

   The VBR-Info header has the following format:

      VBR-Info: md=<domain>; mc=<type-string>; mv=<certifier-list>;




Hoffman, et al.          Expires April 12, 2009                 [Page 4]

Internet-Draft                     VBR                      October 2008


   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.example and
   certifier-b.example.  The signer would add the following to the
   header of its outgoing message.

      VBR-Info: md=somebank.example; mc=transaction;
          mv=certifier-a.example:certifier-b.example;

   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 MUST 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 MUST have identical mc= values.
   The semantics of a message with non-identical mc= categories are
   undefined.


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.example 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:




Hoffman, et al.          Expires April 12, 2009                 [Page 5]

Internet-Draft                     VBR                      October 2008


      somebank.example._vouch.certifier-b.example
      somebank.example._vouch.certifier-a.example

   If the DNS TXT record exists, it contains a space-delimited list of
   all the types that the service certifies, given as lowercase ASCII.
   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
   needs to 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.

   Verifiers MUST check that the TXT record conists of strings of
   lowercase letters separated by spaces, and discard any records not in
   that format.  This defends against misconfigured records and
   irrelevant records synthesized from DNS wildcards.  If more than one
   TXT record exists at a VBR _name, the results are unspecified.
   Verifiers MAY log error messages when they encounter invalid or
   excess TXT records.

   This query method relies on the considerable advantages of existing
   DNS efficiencies, reliability and experience.  The lookup is very
   efficient, and certifiers can add and delete client records as
   quickly as they want.  The lookup also leverages the DNS's negative
   caching ([RFC2308]).


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 needs



Hoffman, et al.          Expires April 12, 2009                 [Page 6]

Internet-Draft                     VBR                      October 2008


   to understand that these semantic definitions can be interpreted in
   very different ways by different people.

   Note that the value 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.

   Three types of content are defined.

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.


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.




Hoffman, et al.          Expires April 12, 2009                 [Page 7]

Internet-Draft                     VBR                      October 2008


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



Hoffman, et al.          Expires April 12, 2009                 [Page 8]

Internet-Draft                     VBR                      October 2008


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


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.


9.  References

9.1.  Normatives References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.







Hoffman, et al.          Expires April 12, 2009                 [Page 9]

Internet-Draft                     VBR                      October 2008


9.2.  Informative References

   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
              NCACHE)", RFC 2308, March 1998.

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


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.


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.




Hoffman, et al.          Expires April 12, 2009                [Page 10]

Internet-Draft                     VBR                      October 2008


B.2.  Changes from 01 to 02

   Updated references to DK and DKIM for RFCs.

B.3.  Changes from 02 to 03

   Minor editorial changes.

   Added the intended status.

B.4.  Changes from 03 to 04

   Changed the examples to use ".example" instead of ".com".

   Updated references to RFC 2822 to RFC 5322.

   Added reference to RFC 2119 and capitalized where appropriate.

   Removed an incorrect comment on intended status.

   Removed the vendor-specific types.

   Added check for invalid TXT records and ones coming from wildcard
   DNS.

   Split the references into normative and informative.


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 12, 2009                [Page 11]

Internet-Draft                     VBR                      October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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 12, 2009                [Page 12]