idnits 2.17.1 draft-levine-appsarea-eaiauth-02.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 (January 21, 2018) is 2259 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 7489 ** Obsolete normative reference: RFC 7601 (Obsoleted by RFC 8601) Summary: 2 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 January 21, 2018 5 Expires: July 25, 2018 7 E-mail Authentication for Internationalized Mail 8 draft-levine-appsarea-eaiauth-02 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 July 25, 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 . . . . . . . . . . . . . . . 3 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 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 SPF, DKIM, and DMARC enable a domain owner to publish e-mail 70 authentication and policy information in the DNS. SPF primarily 71 publishes information about what host addresses are authorized to 72 send mail for a domain. DKIM places cryptographic signatures on 73 e-mail messages, with the validation keys published in the DNS. 74 DMARC publishes policy information related to the domain in the From: 75 header of e-mail messages. 77 In conventional e-mail, all domain names are ASCII in all contexts so 78 there is no question about the representation of the domain names. 79 All internationalized domain names are represented as A-labels 80 [RFC5890] in unencoded message bodies, in SMTP sessions, and in the 81 DNS. Internationalized mail [RFC6530] allows U-labels in SMTP 82 sessions [RFC6531] and in message headers [RFC6532]. 84 Every U-label is equivalent to an A-label, so in principle the choice 85 of label format should not cause any ambiguities. But in practice, 86 consistent use of label formats will make it more likely that mail 87 senders' and receivers' code interoperates. 89 Internationalized mail also allows arbitrary UTF-8 strings in the 90 local parts of mailbox names, which were historically arbitrary 91 ASCII. 93 2. Definitions 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" when 97 written in upper case in in this document are to be interpreted as 98 described in [RFC2119]. 100 The term IDN, for Internationalized Domain Name, refers to either a 101 U-label or an A-label. 103 Since DMARC is not currently a standards track protocol, this 104 specification offers advice rather than requirements for DMARC. 106 3. General principles 108 In headers in EAI mail messages, domain names that were restricted to 109 ASCII can now be U-labels, and mailbox local parts can be arbitrary 110 UTF-8. Header names and other text intended primarily to be 111 interpreted by computers rather than read by people remains ASCII. 113 Strings stored in DNS records remain ASCII since there is no way to 114 tell whether a client retrieving a DNS record expects an EAI or an 115 ASCII result. When a domain name found in a mail header includes 116 U-labels, those labels are translated to A-labels before being looked 117 up in the DNS, as described in [RFC5891]. 119 4. SPF and internationalized mail 121 SPF [RFC7208] uses two identities from the SMTP session, the host 122 name in the EHLO command, and the domain in the address in the MAIL 123 FROM command. Since the EHLO command precedes the server response 124 that tells whether the server supports the SMTPUTF8 extension, an IDN 125 domain name argument MUST be represented as an A-label. An IDN 126 domain name in MAIL FROM can be either U-labels or an A-labels. 128 All U-labels MUST be converted to A-labels before being used for an 129 SPF validation. This includes both the original DNS lookup, 130 described in Section 3 of [RFC7208] and the macro expansion of 131 domain-spec described in section 7. Section 4.3 of [RFC7208] states 132 that all IDNs in an SPF DNS record MUST be A-labels; this rule is 133 unchanged since any SPF record can be used to authorize either EAI or 134 conventional mail. 136 5. DKIM and internationalized mail 138 DKIM [RFC6376] specifies a message header that contains a 139 cryptographic message signature and a DNS record that contains the 140 validation key. 142 Section 3.5 of [RFC6376] states that IDNs in the d=, i=, and s= tags 143 of a DKIM-Signature header MUST be encoded as A-labels. This rule is 144 relaxed only for headers in internationalized messages [RFC6532] so 145 IDNs MAY be represented either as A-labels or U-labels. This 146 provides improved consistency with other headers, particularly since 147 the local-part of the i= tag is likely to be UTF-8 rather than ASCII. 148 When computing or verifying the hash in a DKIM signature as described 149 in section 3.7, the hash MUST use the domain name in the format it 150 occurs in the header. 152 DKIM key records, described in section 3.6.1, do not contain domain 153 names, so there is no change to their specification. 155 6. DMARC and internationalized mail 157 DMARC [RFC7489] defines a policy language that domain owners can 158 specify for the domain of the address in a RFC5322.From header. 160 Section 6.6.1 specifies, somewhat imprecisely, how IDNs in the 161 RFC5322.From address domain are to be handled. That section is 162 updated to say that all U-labels in the domain are converted to 163 A-labels before further processing. Sections 6.7 and 7.1 are 164 similarly updated to say that all U-labels in domains being handled 165 are converted to A-labels before further processing. 167 DMARC policy records, described in section 6.3, can contain e-mail 168 addresses in the rua and ruf tags. Since a policy record can be used 169 for both internationalized and conventional mail, those addresses 170 have to be conventional addresses, not internationalized addresses. 172 7. Authentication-Results and internationalized mail 174 The Authentication-Results [RFC7601] header reports the results of 175 authentication tests made using a variety of authentication schemes. 177 In EAI messages, in every place where a domain name may appear in an 178 Authentication-Results header, that domain name MAY be stored as a 179 U-label. In the ABNF descriptions in section 2.2, each domain-name 180 MAY be a U-label, and each local-part MAY be arbitrary UTF-8. 182 When a domain name is used as an authserv-id described in section 183 2.5, it MAY be a U-label. 185 In section 2.7.1, the domain name in the DKIM header.d field MAY be a 186 U-label. 188 In section 2.7.4, the authentication identity and mailbox MAY include 189 a UTF-8 local-part and U-label domain name. 191 [ allow IDN address in body.smime-identifier in RFC 7281? ] 193 8. IANA Considerations 195 This document makes no request of IANA. 197 9. Security Considerations 199 E-mail is subject to a vast range of threats and abuses. This 200 document attempts to slightly mitigate some of them but does not, as 201 far as the author knows, add any new ones. 203 10. Normative References 205 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 206 Requirement Levels", BCP 14, RFC 2119, 207 DOI 10.17487/RFC2119, March 1997, 208 . 210 [RFC5890] Klensin, J., "Internationalized Domain Names for 211 Applications (IDNA): Definitions and Document Framework", 212 RFC 5890, DOI 10.17487/RFC5890, August 2010, 213 . 215 [RFC5891] Klensin, J., "Internationalized Domain Names in 216 Applications (IDNA): Protocol", RFC 5891, 217 DOI 10.17487/RFC5891, August 2010, 218 . 220 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 221 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 222 RFC 6376, DOI 10.17487/RFC6376, September 2011, 223 . 225 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 226 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, 227 February 2012, . 229 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized 230 Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, 231 . 233 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 234 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 235 2012, . 237 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 238 Authorizing Use of Domains in Email, Version 1", RFC 7208, 239 DOI 10.17487/RFC7208, April 2014, 240 . 242 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 243 Message Authentication, Reporting, and Conformance 244 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 245 . 247 [RFC7601] Kucherawy, M., "Message Header Field for Indicating 248 Message Authentication Status", RFC 7601, 249 DOI 10.17487/RFC7601, August 2015, 250 . 252 Author's Address 254 John Levine 255 Taughannock Networks 256 PO Box 727 257 Trumansburg, NY 14886 259 Phone: +1 831 480 2300 260 Email: standards@taugh.com 261 URI: http://jl.ly