[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 5518

Network Working Group                                         P. Hoffman
Internet-Draft                                                 J. Levine
Intended status: Standards Track                Domain Assurance Council
Expires: August 29, 2009                                     A. Hathcock
                                                      Alt-N Technologies
                                                       February 25, 2009


                           Vouch By Reference
                        draft-hoffman-dac-vbr-07

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   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 29, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Hoffman, et al.          Expires August 29, 2009                [Page 1]

Internet-Draft                     VBR                     February 2009


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

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
     1.1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Use of the VBR-Info Header Field . . . . . . . . . . . . . . .  4
   3.  Validation Process . . . . . . . . . . . . . . . . . . . . . .  4
   4.  The VBR-Info Header Field  . . . . . . . . . . . . . . . . . .  5
     4.1.  Syntax of VBR-Info Header Fields . . . . . . . . . . . . .  5
   5.  DNS Query  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   6.  Types of Message Content . . . . . . . . . . . . . . . . . . .  7
     6.1.  All  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.2.  List . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.3.  Transaction  . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Obtaining a Useful Domain Name . . . . . . . . . . . . . . . .  8
     7.1.  DKIM . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     7.2.  DomainKeys . . . . . . . . . . . . . . . . . . . . . . . .  9
     7.3.  SPF  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     7.4.  Sender ID  . . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     10.2. Informative References . . . . . . . . . . . . . . . . . . 11
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 11
   Appendix B.  Change Log  . . . . . . . . . . . . . . . . . . . . . 12
     B.1.  Changes from 00 to 01  . . . . . . . . . . . . . . . . . . 12
     B.2.  Changes from 01 to 02  . . . . . . . . . . . . . . . . . . 12
     B.3.  Changes from 02 to 03  . . . . . . . . . . . . . . . . . . 12
     B.4.  Changes from 03 to 04  . . . . . . . . . . . . . . . . . . 12
     B.5.  Changes from 04 to 05  . . . . . . . . . . . . . . . . . . 13
     B.6.  Changes from 05 to 06  . . . . . . . . . . . . . . . . . . 13
     B.7.  Changes from 06 to 07  . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14




Hoffman, et al.          Expires August 29, 2009                [Page 2]

Internet-Draft                     VBR                     February 2009


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

   If a recipient uses the results of vouching to adjust spam scores on
   incoming email, that recipient is placing a great deal of operational
   trust and power in the vouching service.  Therefore, recipients need
   to select such services with care.  Further, such recipients may want
   to select more than one vouching service in order to avoid a single
   point of failure for setting spam scores.





Hoffman, et al.          Expires August 29, 2009                [Page 3]

Internet-Draft                     VBR                     February 2009


1.1.  Definitions

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


2.  Use of the VBR-Info Header Field

   A sender uses VBR to indicate which domain certification services the
   sender believes will vouch for a particular piece of mail.  The
   certification service uses VBR to state for which signatures it will
   vouch.  This protocol uses the DNS to distribute the certification
   information.

   A message may have multiple VBR-Info header fields.  This means that,
   in the terminology of RFC 5322, 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 field 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 formal syntax of the header field 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 a locally-
       defined set of preferred vouching services
   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 August 29, 2009                [Page 4]

Internet-Draft                     VBR                     February 2009


4.  The VBR-Info Header Field

   The VBR-Info header field has the following format:

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

   where <domain> is the domain for which vouching is offered, <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.  The elements in the domain, type-string, and
   certifier-list must not have any white space in them.

   For example, assume that the signer has two companies that 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 header parameters 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 field are
   equivalent, although conventionally the contents 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 field, verifiers
   SHOULD check each in turn or in parallel until either a satisfactory
   certifier is found or all the header fields have been checked.  All
   of the VBR-Info header fields in a single message MUST have identical
   mc= values.

4.1.  Syntax of VBR-Info Header Fields

   In the ABNF below, the ALPHA and DIGIT tokens are imported from
   [RFC5234], and the FWS and domain-name tokens are imported from
   [RFC4871].









Hoffman, et al.          Expires August 29, 2009                [Page 5]

Internet-Draft                     VBR                     February 2009


   vbr-info-header =  "VBR-Info:" 1*([FWS] element [FWS] ";")
   element = md-element / mc-element / mv-element

   md-element = "md=" [FWS] domain-name

   mc-element = "mc=" [FWS] type-string
   type-string = "all" / "list" / "transaction"

   mv-element = "mv=" [FWS] certifier-list
   certifier-list = domain-name *(":" domain-name)


5.  DNS Query

   When a recipient wants to check whether a certification claim is
   valid, 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 marshals 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.  The recipient
   looks up the domain name in the DNS in the exact same manner it looks
   up all other domain names.

   For example, if a message signed by somebank.example contained the
   VBR-Info header field above, the receiver might look up either or
   both of the following names, depending on which vouching service it
   trusts:

      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 certifier has vouched for the validity of the



Hoffman, et al.          Expires August 29, 2009                [Page 6]

Internet-Draft                     VBR                     February 2009


   message.  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 host 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.

   If the RDATA in the TXT record contains multiple character-strings
   (as defined in section 3.3 of [RFC1035]), the code handling that
   reply from DNS MUST assemble all of these marshalled text blocks into
   a single one before any syntactical verification takes place.

   Verifiers MUST then check that the TXT record consists 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.

   The VBR record MUST have only one TXT record.

   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 for which a certifier can
   vouch.  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 as specifically as possible, but the reader needs 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 anyone to certify its advertising mail, but has
   a certifier for its 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



Hoffman, et al.          Expires August 29, 2009                [Page 7]

Internet-Draft                     VBR                     February 2009


   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, 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.  Senders SHOULD use DKIM (and MAY use
   DomainKeys, SPF, or SenderID) to give an accountable identity for the
   sender.

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 field or adding bogus
      VBR-Info header fields.



Hoffman, et al.          Expires August 29, 2009                [Page 8]

Internet-Draft                     VBR                     February 2009


   o  The VBR-Info header field SHOULD be added in 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 field or adding bogus VBR-Info
      header fields.
   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 the
   first parameter to the SMTP MAIL command.

   A domain is valid for use with VBR only when the SPF process produces
   a "pass" result.

7.4.  Sender ID

   Sender ID, [RFC4406], defines an accountable identity by using an
   existing message address known as the Purported Responsible Address
   [RFC4407] 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



Hoffman, et al.          Expires August 29, 2009                [Page 9]

Internet-Draft                     VBR                     February 2009


   same value as the domain name in the Purported Responsible Address in
   the message.

   A domain is valid for use with VBR only when the Sender ID process
   produces a "pass" 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 field 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 header fields
   they process in a single message in order to protect themselves from
   a make-work or denial-of-service attack.


9.  IANA Considerations

   IANA is requested to register the VBR-Info header field in the
   Message Header Fields Registry ([RFC3864]) as follows:

   Header field name: VBR-Info

   Applicable protocol: mail

   Status: standard

   Author/Change controller: IETF

   Specification document(s): (Note to RFC Editor: the RFC number of
   this document if approved)

   Related information: none


10.  References







Hoffman, et al.          Expires August 29, 2009               [Page 10]

Internet-Draft                     VBR                     February 2009


10.1.  Normative 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.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

10.2.  Informative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

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

   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
              Procedures for Message Header Fields", BCP 90, RFC 3864,
              September 2004.

   [RFC4406]  Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail",
              RFC 4406, April 2006.

   [RFC4407]  Lyon, J., "Purported Responsible Address in E-Mail
              Messages", RFC 4407, 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 and
   Murray Kucherawy.



Hoffman, et al.          Expires August 29, 2009               [Page 11]

Internet-Draft                     VBR                     February 2009


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.

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.





Hoffman, et al.          Expires August 29, 2009               [Page 12]

Internet-Draft                     VBR                     February 2009


B.5.  Changes from 04 to 05

   Small editorial changes received during IETF Last Call.

   In Section 3, changed "another source" to "a preferred local set of
   vouching services".

   Added the section with ABNF to Section 4.

   In Section 5, changed "exists at a VBR _name" to "exists at a name
   from a VBR record".

   In Section 5, added "If the RDATA in the TXT record contains multiple
   character-strings..." and reorganized some surrounding text.

   Added "Senders SHOULD use DKIM (and MAY use DomainKeys, SPF, or
   SenderID) to give an accountable identity for the sender." to the
   beginning of Section 7.

   Added the IANA Considerations to add VBR-Info to the Message Header
   Fields Registry.

   Added reference to RFC 4407.

   Added Murray Kucherawy to acknowledgements.

B.6.  Changes from 05 to 06

   Added the paragraph at the end of the introduction about recipients
   using care when they select reputation providers.

   Removed "The semantics of a message with non-identical mc= categories
   are undefined" from the last paragraph of Section 4.

   Added "The recipient looks up the domain name in the DNS in the exact
   same manner it looks up all other domain names" near the beginning of
   Section 5.

   Changed "If more than one TXT record exists at a name from a VBR
   record, the results are unspecified" to "The VBR record MUST have
   only one TXT record" near the end of Section 5.

   Near the end of Section 5, changed "valid domain name" to "valid host
   name".







Hoffman, et al.          Expires August 29, 2009               [Page 13]

Internet-Draft                     VBR                     February 2009


B.7.  Changes from 06 to 07

   In Section 4, changed "All three header fields" to "All three header
   parameters".

   In Section 4.1, changed *FWS to [FWS] in the ABNF.


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


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/