idnits 2.17.1 draft-kucherawy-authres-vbr-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 18, 2011) is 4846 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5451 (ref. 'AUTHRES') (Obsoleted by RFC 7001) -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual submission M. Kucherawy 3 Internet-Draft Cloudmark, Inc. 4 Intended status: Standards Track January 18, 2011 5 Expires: July 22, 2011 7 Authentication-Results Registration For Vouch By Reference Results 8 draft-kucherawy-authres-vbr-04 10 Abstract 12 This memo updates the registry of properties in Authentication- 13 Results: message header fields to allow relaying of the results of a 14 Vouch By Reference query. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on July 22, 2011. 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 58 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 59 Appendix A. Authentication-Results Examples . . . . . . . . . . . 6 60 A.1. VBR Results . . . . . . . . . . . . . . . . . . . . . . . . 7 61 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . . 7 63 1. Introduction 65 [AUTHRES] defined a new header field for electronic mail messages 66 that presents the results of a message authentication effort in a 67 machine-readable format. In the interim, a proposal for rudimentary 68 domain-level reputation called Vouch By Reference [VBR] was published 69 and is now beginning to see popular use. 71 This memo thus registers an additional reporting property allowing a 72 VBR result to be relayed as an annotation in a message header. 74 2. Keywords 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [KEYWORDS]. 80 3. Discussion 82 Vouch By Reference [VBR] introduced a mechanism by which a message 83 receiver can query a "vouching" service to determine whether or not a 84 trusted third party is willing to state that mail from a particular 85 source can be considered legitimate. When this assessment is done at 86 an inbound border mail gateway, it would be useful to relay the 87 result of that assessment to internal mail entities such as filters 88 or user agents. 90 Reactions to the information contained in an Authentication-Results 91 header field that contains VBR (or any) results are not specified 92 here as they are entirely a matter of local policy at the receiver. 94 4. Definition 96 This memo adds to the "Email Authentication Method Name Registry", 97 created by IANA upon publication of [AUTHRES], the following: 99 o The method "vbr"; and 101 o Associated with that method, the properties (reporting items) 102 "header.md" and "header.mv". 104 If "header.md" is present, its value MUST be the DNS domain name 105 about which a VBR query was made. If "header.mv" is present, its 106 value MUST be the DNS domain name that was queried as the potential 107 voucher for the "header.md" domain. 109 If the VBR query was made based on the content of a "VBR-Info" header 110 field present on an incoming message, "header.md" is typically taken 111 from the "md" tag of the "VBR-Info" header field and "header.mv" is 112 typically one of the values of the "mv" tag in the "VBR-Info" header 113 field on that message. However, [VBR] permits a different mechanism 114 for selection of the subject domain and/or list of vouchers, ignoring 115 those present in any "VBR-Info" header field the message might have 116 included. A server could even conduct a VBR query when no "VBR-Info" 117 field was present based on locally configured policy options. Where 118 such mechanisms are applied, the verifying server MAY generate an 119 Authentication-Results field to relay the results of the VBR query. 121 This memo also adds to the "Email Authentication Results Name 122 Registry" the following result codes and definitions: 124 none: No valid VBR-Info header was found in the message, or a domain 125 name to be queried could not be determined. 127 pass: A VBR query was completed and the vouching service queried 128 gave a positive response. 130 fail: A VBR query was completed and the vouching service queried did 131 not give a positive response, or the message contained multiple 132 VBR-Info header fields with different "mc" values. 134 temperror: A VBR query was attempted but could not be completed due 135 to some error that is likely transient in nature such as a 136 temporary DNS error. A later attempt may produce a final result. 138 permerror: A VBR query was attempted but could not be completed due 139 to some error that is likely not transient in nature such as a 140 permanent DNS error. A later attempt is unlikely to produce a 141 final result. 143 5. IANA Considerations 145 Per [IANA-CONSIDERATIONS], the following item is added to the "Email 146 Authentication Method Name Registry": 148 +------------+----------+--------+----------------+-----------------+ 149 | Method | Defined | ptype | property | value | 150 +------------+----------+--------+----------------+-----------------+ 151 | vbr | RFC5518 | header | md | DNS domain name | 152 | | | | | used as the | 153 | | | | | subject of a | 154 | | | | | VBR query | 155 +------------+----------+--------+----------------+-----------------+ 156 | vbr | RFC5518 | header | mv | DNS domain name | 157 | | | | | of the entity | 158 | | | | | acting as | 159 | | | | | the voucher | 160 +------------+----------+--------+----------------+-----------------+ 162 Also, the following item is added to the "Email Authentication Method 163 Results Registry": 165 +-----------+--------------+------------+---------+-----------------+ 166 | Code | Existing/New | Defined In | Method | Meaning | 167 +-----------+--------------+------------+---------+-----------------+ 168 | none | existing | RFC5451 | vbr | Section 4 | 169 | | | | (added) | | 170 +-----------+--------------+------------+---------+-----------------+ 171 | pass | existing | RFC5451 | vbr | Section 4 | 172 | | | | (added) | | 173 +-----------+--------------+------------+---------+-----------------+ 174 | fail | existing | RFC5451 | vbr | Section 4 | 175 | | | | (added) | | 176 +-----------+--------------+------------+---------+-----------------+ 177 | temperror | existing | RFC5451 | vbr | Section 4 | 178 | | | | (added) | | 179 +-----------+--------------+------------+---------+-----------------+ 180 | permerror | existing | RFC5451 | vbr | Section 4 | 181 | | | | (added) | | 182 +-----------+--------------+------------+---------+-----------------+ 184 6. Security Considerations 186 This memo creates a mechanism for relaying [VBR] results using the 187 structure already defined by [AUTHRES]. The Security Considerations 188 sections of those documents should be consulted. 190 7. References 192 7.1. Normative References 194 [AUTHRES] Kucherawy, M., "Message Header Field for 195 Indicating Message Authentication Status", 196 RFC 5451, April 2009. 198 [KEYWORDS] Bradner, S., "Key words for use in RFCs to 199 Indicate Requirement Levels", BCP 14, 200 RFC 2119, March 1997. 202 [VBR] Hoffman, P., Levine, J., and A. Hathcock, 203 "Vouch By Reference", RFC 5518, April 2009. 205 7.2. Informative References 207 [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for 208 Writing an IANA Considerations Section in 209 RFCs", BCP 26, RFC 5226, May 2008. 211 Appendix A. Authentication-Results Examples 213 This section presents an example of the use of this new item header 214 field to indicate VBR results. 216 A.1. VBR Results 218 A message that triggered a VBR query, returning a result: 220 Authentication-Results: mail-router.example.net; 221 dkim=pass (good signature) header.d=newyork.example.com 222 header.b=oINEO8hg; 223 vbr=pass (voucher.example.net) 224 header.md=newyork.example.com 225 header.mv=voucher.example.org 226 Received: from newyork.example.com 227 (newyork.example.com [192.0.2.250]) 228 by mail-router.example.net (8.11.6/8.11.6) 229 for 230 with ESMTP id i7PK0sH7021929; 231 Fri, Feb 15 2002 17:19:22 -0800 232 DKIM-Signature: v=1; a=rsa-sha256; s=rashani; 233 d=newyork.example.com; 234 t=1188964191; c=relaxed/simple; 235 h=From:Date:To:VBR-Info:Message-Id:Subject; 236 bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=; 237 b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3= 238 From: sender@newyork.example.com 239 Date: Fri, Feb 15 2002 16:54:30 -0800 240 To: meetings@example.net 241 VBR-Info: md=newyork.example.com; mc=list; 242 mv=voucher.example.org 243 Message-Id: <12345.abc@newyork.example.com> 244 Subject: here's a sample 246 Example 1: Header field reporting results from a VBR query 248 Here we see an example of a message that was signed using DKIM and 249 also included a VBR-Info header field. On receipt it is found that 250 the "md=" field in the latter and the "d=" field in the former 251 matched and also that the DKIM signature verified, so a VBR query was 252 performed. The vouching service, voucher.example.org, indicated the 253 sender can be trusted, so a "pass" result is included in the 254 Authentication-Results field affixed prior to delivery. 256 Appendix B. Acknowledgements 258 The author wishes to acknowledge the following for their review and 259 constructive criticism of this proposal: JD Falk, John Levine, 260 Alessandro Vesely 262 Author's Address 264 Murray S. Kucherawy 265 Cloudmark, Inc. 266 128 King St., 2nd Floor 267 San Francisco, CA 94107 268 US 270 Phone: +1 415 946 3800 271 EMail: msk@cloudmark.com