idnits 2.17.1 draft-levine-appsarea-eaiauth-03.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 7, 2018) is 2269 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) ** Downref: Normative reference to an Informational RFC: RFC 7281 ** Downref: Normative reference to an Informational RFC: RFC 7489 ** Obsolete normative reference: RFC 7601 (Obsoleted by RFC 8601) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Levine 3 Internet-Draft Taughannock Networks 4 Intended status: Standards Track February 7, 2018 5 Expires: August 11, 2018 7 E-mail Authentication for Internationalized Mail 8 draft-levine-appsarea-eaiauth-03 10 Abstract 12 SPF, DKIM, and DMARC enable a domain owner to publish e-mail 13 authentication and policy information in the DNS. In 14 internationalized e-mail, domain names can occur both as U-labels and 15 A-labels. The Authentication-Results header reports the result of 16 authentication checks made with SPF, DKIM, DMARC, and other schemes. 17 This specification clarifies when to use which form of domain names 18 when using SPF, DKIM, and DMARC and when creating Authentication- 19 Results headers. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 11, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. General principles . . . . . . . . . . . . . . . . . . . . . 3 58 4. SPF and internationalized mail . . . . . . . . . . . . . . . 3 59 5. DKIM and internationalized mail . . . . . . . . . . . . . . . 4 60 6. DMARC and internationalized mail . . . . . . . . . . . . . . 4 61 7. Authentication-Results and internationalized mail . . . . . . 4 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 10. Normative References . . . . . . . . . . . . . . . . . . . . 5 65 Appendix A. Change history . . . . . . . . . . . . . . . . . . . 6 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 SPF, DKIM, and DMARC enable a domain owner to publish e-mail 71 authentication and policy information in the DNS. SPF primarily 72 publishes information about what host addresses are authorized to 73 send mail for a domain. DKIM places cryptographic signatures on 74 e-mail messages, with the validation keys published in the DNS. 75 DMARC publishes policy information related to the domain in the From: 76 header of e-mail messages. 78 In conventional e-mail, all domain names are ASCII in all contexts so 79 there is no question about the representation of the domain names. 80 All internationalized domain names are represented as A-labels 81 [RFC5890] in unencoded message bodies, in SMTP sessions, and in the 82 DNS. Internationalized mail [RFC6530] allows U-labels in SMTP 83 sessions [RFC6531] and in message headers [RFC6532]. 85 Every U-label is equivalent to an A-label, so in principle the choice 86 of label format should not cause any ambiguities. But in practice, 87 consistent use of label formats will make it more likely that mail 88 senders' and receivers' code interoperates. 90 Internationalized mail also allows arbitrary UTF-8 strings in the 91 local parts of mailbox names, which were historically arbitrary 92 ASCII. 94 2. Definitions 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" when 98 written in upper case in in this document are to be interpreted as 99 described in [RFC2119]. 101 The term IDN, for Internationalized Domain Name, refers to either a 102 U-label or an A-label. 104 Since DMARC is not currently a standards track protocol, this 105 specification offers advice rather than requirements for DMARC. 107 3. General principles 109 In headers in EAI mail messages, domain names that were restricted to 110 ASCII can now be U-labels, and mailbox local parts can be arbitrary 111 UTF-8. Header names and other text intended primarily to be 112 interpreted by computers rather than read by people remains ASCII. 114 Strings stored in DNS records remain ASCII since there is no way to 115 tell whether a client retrieving a DNS record expects an EAI or an 116 ASCII result. When a domain name found in a mail header includes 117 U-labels, those labels are translated to A-labels before being looked 118 up in the DNS, as described in [RFC5891]. 120 4. SPF and internationalized mail 122 SPF [RFC7208] uses two identities from the SMTP session, the host 123 name in the EHLO command, and the domain in the address in the MAIL 124 FROM command. Since the EHLO command precedes the server response 125 that tells whether the server supports the SMTPUTF8 extension, an IDN 126 domain name argument MUST be represented as an A-label. An IDN 127 domain name in MAIL FROM can be either U-labels or an A-labels. 129 All U-labels MUST be converted to A-labels before being used for an 130 SPF validation. This includes both the original DNS lookup, 131 described in Section 3 of [RFC7208] and the macro expansion of 132 domain-spec described in section 7. Section 4.3 of [RFC7208] states 133 that all IDNs in an SPF DNS record MUST be A-labels; this rule is 134 unchanged since any SPF record can be used to authorize either EAI or 135 conventional mail. 137 SPF macros %s and %l expand the local-part of the sender's mailbox. 138 If the local-part contains non-ASCII characters, terms that include 139 %s or %l do not match anything. 141 5. DKIM and internationalized mail 143 DKIM [RFC6376] specifies a message header that contains a 144 cryptographic message signature and a DNS record that contains the 145 validation key. 147 Section 3.5 of [RFC6376] states that IDNs in the d=, i=, and s= tags 148 of a DKIM-Signature header MUST be encoded as A-labels. This rule is 149 relaxed only for headers in internationalized messages [RFC6532] so 150 IDNs MAY be represented either as A-labels or U-labels. This 151 provides improved consistency with other headers, particularly since 152 the local-part of the i= tag is likely to be UTF-8 rather than ASCII. 153 When computing or verifying the hash in a DKIM signature as described 154 in section 3.7, the hash MUST use the domain name in the format it 155 occurs in the header. 157 DKIM key records, described in section 3.6.1, do not contain domain 158 names, so there is no change to their specification. 160 6. DMARC and internationalized mail 162 DMARC [RFC7489] defines a policy language that domain owners can 163 specify for the domain of the address in a RFC5322.From header. 165 Section 6.6.1 specifies, somewhat imprecisely, how IDNs in the 166 RFC5322.From address domain are to be handled. That section is 167 updated to say that all U-labels in the domain are converted to 168 A-labels before further processing. Sections 6.7 and 7.1 are 169 similarly updated to say that all U-labels in domains being handled 170 are converted to A-labels before further processing. 172 DMARC policy records, described in section 6.3, can contain e-mail 173 addresses in the rua and ruf tags. Since a policy record can be used 174 for both internationalized and conventional mail, those addresses 175 have to be conventional addresses, not internationalized addresses. 177 7. Authentication-Results and internationalized mail 179 The Authentication-Results [RFC7601] header reports the results of 180 authentication tests made using a variety of authentication schemes. 182 In EAI messages, in every place where a domain name may appear in an 183 Authentication-Results header, that domain name MAY be stored as a 184 U-label. In the ABNF descriptions in section 2.2, each domain-name 185 MAY be a U-label, and each local-part MAY be arbitrary UTF-8. 187 When a domain name is used as an authserv-id described in section 188 2.5, it MAY be a U-label. 190 In section 2.7.1, the domain name in the DKIM header.d field MAY be a 191 U-label. 193 In section 2.7.4, the authentication identity and mailbox MAY include 194 a UTF-8 local-part and U-label domain name. 196 In S/MIME signature verification [RFC7281] results, the body.smime- 197 identifier parameter MAY include a UTF-8 local-part and U-label 198 domain name. 200 8. IANA Considerations 202 This document makes no request of IANA. 204 9. Security Considerations 206 E-mail is subject to a vast range of threats and abuses. This 207 document attempts to slightly mitigate some of them but does not, as 208 far as the author knows, add any new ones. 210 10. Normative References 212 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 213 Requirement Levels", BCP 14, RFC 2119, 214 DOI 10.17487/RFC2119, March 1997, 215 . 217 [RFC5890] Klensin, J., "Internationalized Domain Names for 218 Applications (IDNA): Definitions and Document Framework", 219 RFC 5890, DOI 10.17487/RFC5890, August 2010, 220 . 222 [RFC5891] Klensin, J., "Internationalized Domain Names in 223 Applications (IDNA): Protocol", RFC 5891, 224 DOI 10.17487/RFC5891, August 2010, 225 . 227 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 228 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 229 RFC 6376, DOI 10.17487/RFC6376, September 2011, 230 . 232 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 233 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, 234 February 2012, . 236 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized 237 Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, 238 . 240 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 241 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 242 2012, . 244 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 245 Authorizing Use of Domains in Email, Version 1", RFC 7208, 246 DOI 10.17487/RFC7208, April 2014, 247 . 249 [RFC7281] Melnikov, A., "Authentication-Results Registration for 250 S/MIME Signature Verification", RFC 7281, 251 DOI 10.17487/RFC7281, June 2014, 252 . 254 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 255 Message Authentication, Reporting, and Conformance 256 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 257 . 259 [RFC7601] Kucherawy, M., "Message Header Field for Indicating 260 Message Authentication Status", RFC 7601, 261 DOI 10.17487/RFC7601, August 2015, 262 . 264 Appendix A. Change history 266 02 to 03 SPF local-part macros don't match non-ASCII. Add S/MIME 267 auth results. 269 Author's Address 271 John Levine 272 Taughannock Networks 273 PO Box 727 274 Trumansburg, NY 14886 276 Phone: +1 831 480 2300 277 Email: standards@taugh.com 278 URI: http://jl.ly