idnits 2.17.1 draft-ietf-dmarc-eaiauth-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7489, but the abstract doesn't seem to directly say this. It does mention RFC7489 though, so this could be OK. -- The draft header indicates that this document updates RFC6376, but the abstract doesn't seem to directly say this. It does mention RFC6376 though, so this could be OK. -- The draft header indicates that this document updates RFC7208, but the abstract doesn't seem to directly say this. It does mention RFC7208 though, so this could be OK. 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 (March 25, 2019) is 1852 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 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). 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 Updates: 6376, 7208, 7489 (if approved) March 25, 2019 5 Intended status: Standards Track 6 Expires: September 26, 2019 8 E-mail Authentication for Internationalized Mail 9 draft-ietf-dmarc-eaiauth-04 11 Abstract 13 SPF (RFC7208), DKIM (RFC6376), and DMARC (RFC7489) enable a domain 14 owner to publish e-mail authentication and policy information in the 15 DNS. In internationalized e-mail, domain names can occur both as 16 U-labels and A-labels. This specification updates the SPF, DKIM, and 17 DMARC specifications to clarify which form of internationalized 18 domain names to use in those specifications. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 26, 2019. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. General principles . . . . . . . . . . . . . . . . . . . . . 3 57 4. SPF and internationalized mail . . . . . . . . . . . . . . . 3 58 5. DKIM and internationalized mail . . . . . . . . . . . . . . . 4 59 6. DMARC and internationalized mail . . . . . . . . . . . . . . 4 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 63 Appendix A. Change history . . . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 SPF [RFC7208], DKIM [RFC6376], and DMARC [RFC7489] enable a domain 69 owner to publish e-mail authentication and policy information in the 70 DNS. SPF primarily publishes information about what host addresses 71 are authorized to send mail for a domain. DKIM places cryptographic 72 signatures on e-mail messages, with the validation keys published in 73 the DNS. DMARC publishes policy information related to the domain in 74 the From: header of e-mail messages. 76 In conventional e-mail, all domain names are ASCII in all contexts so 77 there is no question about the representation of the domain names. 78 All internationalized domain names are represented as A-labels 79 [RFC5890] in message headers, in SMTP sessions, and in the DNS. 80 Internationalized mail [RFC6530] allows U-labels in SMTP sessions 81 [RFC6531] and in message headers [RFC6532]. 83 Every U-label is equivalent to an A-label, so in principle the choice 84 of label format should not cause any ambiguities. But in practice, 85 consistent use of label formats will make it more likely that mail 86 senders' and receivers' code interoperates. 88 Internationalized mail also allows UTF-8 encoded Unicode characters 89 in the local parts of mailbox names, which were historically only 90 ASCII. 92 2. Definitions 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in BCP 97 14 [RFC2119] and [RFC8174]. when they appear in all capitals, as 98 shown here. 100 The term IDN, for Internationalized Domain Name, refers to a domain 101 name containing either U-labels or A-labels. 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 UTF-8. 110 Header names and other text intended primarily to be interpreted by 111 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 argument MUST be represented as an A-label. An IDN in MAIL FROM can 126 be either U-labels or 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 SPF macros %{s} and %{l} expand the local-part of the sender's 137 mailbox. If the local-part contains non-ASCII characters, terms that 138 include %{s} or %{l} do not match anything. (Note that unlike 139 U-labels in domains, there is no way to rewrite non-ASCII local parts 140 into ASCII.) 142 5. DKIM and internationalized mail 144 DKIM [RFC6376] specifies a message header that contains a 145 cryptographic message signature and a DNS record that contains the 146 validation key. 148 Section 2.11 of [RFC6376] defines dkim-quoted-printable. Its 149 definition is modified in messages with internationalized headers so 150 that non-ASCII UTF-8 characters need not be quoted. The ABNF for 151 dkim-safe-char in those messages is replaced by the following, adding 152 non-ASCII UTF-8 characters from [RFC3629]: 154 dkim-safe-char = %x21-3A / %x3C / %x3E-7E / 155 UTF8-2 / UTF8-3 / UTF8-4 156 ; '!' - ':', '<', '>' - '~', non-ASCII 158 UTF8-2 = 160 UTF8-3 = 162 UTF8-4 = 164 Section 3.5 of [RFC6376] states that IDNs in the d=, i=, and s= tags 165 of a DKIM-Signature header MUST be encoded as A-labels. This rule is 166 relaxed only for internationalized messages headers [RFC6532] so IDNs 167 SHOULD be represented as U-labels but MAY be A-labels. This provides 168 improved consistency with other headers. The set of allowable 169 characters in the local-part of an i= tag is extended as described in 170 [RFC6532]. When computing or verifying the hash in a DKIM signature 171 as described in section 3.7, the hash MUST use the domain name in the 172 format it occurs in the header. 174 Section 3.4.2 of [RFC6376] describes relaxed header canonicalization. 175 Its first step converts all header field names from upper case to 176 lower case. Field names are restricted to printable ASCII (see 177 [RFC5322] section 3.6.8) so this case conversion remains the usual 178 ASCII conversion. 180 DKIM key records, described in section 3.6.1, do not contain domain 181 names, so there is no change to their specification. 183 6. DMARC and internationalized mail 185 DMARC [RFC7489] defines a policy language that domain owners can 186 specify for the domain of the address in a RFC5322.From header. 188 Section 6.6.1 specifies, somewhat imprecisely, how IDNs in the 189 RFC5322.From address domain are to be handled. That section is 190 updated to say that all U-labels in the domain are converted to 191 A-labels before further processing. Sections 6.7 and 7.1 are 192 similarly updated to say that all U-labels in domains being handled 193 are converted to A-labels before further processing. 195 DMARC policy records, described in sections 6.3 and 7.1, can contain 196 e-mail addresses in the rua and ruf tags. Since a policy record can 197 be used for both internationalized and conventional mail, those 198 addresses still have to be conventional addresses, not 199 internationalized addresses. 201 7. IANA Considerations 203 This document makes no request of IANA. 205 8. Security Considerations 207 E-mail is subject to a vast range of threats and abuses. This 208 document attempts to slightly mitigate some of them but does not, as 209 far as the author knows, add any new ones. The updates to SPF, DKIM, 210 and DMARC are intended to allow the respective specifications work as 211 reliably on internationalized mail as they do on ASCII mail, so that 212 applications that use them, such as some kinds of spam and phish 213 filtering, can work more reliably on internationalized mail. 215 9. Normative References 217 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 218 Requirement Levels", BCP 14, RFC 2119, 219 DOI 10.17487/RFC2119, March 1997, 220 . 222 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 223 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 224 2003, . 226 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 227 DOI 10.17487/RFC5322, October 2008, 228 . 230 [RFC5890] Klensin, J., "Internationalized Domain Names for 231 Applications (IDNA): Definitions and Document Framework", 232 RFC 5890, DOI 10.17487/RFC5890, August 2010, 233 . 235 [RFC5891] Klensin, J., "Internationalized Domain Names in 236 Applications (IDNA): Protocol", RFC 5891, 237 DOI 10.17487/RFC5891, August 2010, 238 . 240 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 241 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 242 RFC 6376, DOI 10.17487/RFC6376, September 2011, 243 . 245 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 246 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, 247 February 2012, . 249 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized 250 Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, 251 . 253 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 254 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 255 2012, . 257 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 258 Authorizing Use of Domains in Email, Version 1", RFC 7208, 259 DOI 10.17487/RFC7208, April 2014, 260 . 262 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 263 Message Authentication, Reporting, and Conformance 264 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 265 . 267 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 268 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 269 May 2017, . 271 Appendix A. Change history 273 03 to 04 remove dangling A-R reference, add more i18nish and 274 security goodness 276 02 to 03 minor edits per Alexey 278 01 to 02 update references 280 00 to 01 Relaxed canon, Typos 282 00 First WG version 284 Author's Address 286 John Levine 287 Taughannock Networks 288 PO Box 727 289 Trumansburg, NY 14886 291 Email: standards@taugh.com 292 URI: http://jl.ly