idnits 2.17.1 draft-ietf-dmarc-eaiauth-06.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 date (April 11, 2019) is 1813 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 (~~), 1 warning (==), 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) April 11, 2019 5 Intended status: Standards Track 6 Expires: October 13, 2019 8 E-mail Authentication for Internationalized Mail 9 draft-ietf-dmarc-eaiauth-06 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 October 13, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . 5 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 field 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 header fields, in SMTP sessions, and in the DNS. 81 Internationalized mail [RFC6530], (generally called EAI for E-mail 82 Address Internationalization), allows U-labels in SMTP sessions 83 [RFC6531] and in message header fields [RFC6532]. 85 Every U-label is equivalent to an A-label, so in principle the choice 86 of label format will not cause 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 UTF-8 encoded Unicode characters 91 in the local parts of mailbox names, which were historically only 92 ASCII. 94 2. Definitions 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in BCP 99 14 [RFC2119] [RFC8174] when, and only when, they appear in all 100 capitals, as shown here. 102 The term IDN, for Internationalized Domain Name, refers to a domain 103 name containing either U-labels or A-labels. 105 Since DMARC is not currently a standards track protocol, this 106 specification offers advice rather than requirements for DMARC. 108 3. General principles 110 In headers in EAI mail messages, domain names that were restricted to 111 ASCII can be U-labels, and mailbox local parts can be UTF-8. Header 112 field names and other text intended primarily to be interpreted by 113 computers rather than read by people remains ASCII. 115 Strings stored in DNS records remain ASCII since there is no way to 116 tell whether a client retrieving a DNS record expects an EAI or an 117 ASCII result. When a domain name found in a mail header field 118 includes U-labels, those labels are translated to A-labels before 119 being looked up in the DNS, as described in [RFC5891]. 121 4. SPF and internationalized mail 123 SPF [RFC7208] uses two identities from the SMTP session, the host 124 name in the EHLO command, and the domain in the address in the MAIL 125 FROM command. Since the EHLO command precedes the server response 126 that tells whether the server supports the SMTPUTF8 extension, an IDN 127 host name MUST be represented as A-labels. An IDN in MAIL FROM can 128 be either U-labels or A-labels. 130 All U-labels MUST be converted to A-labels before being used for an 131 SPF validation. This includes both the original DNS lookup, 132 described in Section 3 of [RFC7208] and the macro expansion of 133 domain-spec described in section 7. Section 4.3 of [RFC7208] states 134 that all IDNs in an SPF DNS record MUST be A-labels; this rule is 135 unchanged since any SPF record can be used to authorize either EAI or 136 conventional mail. 138 SPF macros %{s} and %{l} expand the local-part of the sender's 139 mailbox. If the local-part contains non-ASCII characters, terms that 140 include %{s} or %{l} do not match anything, because non-ASCII local 141 parts cannot be used as the DNS labels the macros are intended to 142 match. Since these macros are rarely used, this is unlikely to be an 143 issue in practice. 145 5. DKIM and internationalized mail 147 DKIM [RFC6376] specifies a mail header field that contains a 148 cryptographic message signature and a DNS record that contains the 149 validation key. 151 Section 2.11 of [RFC6376] defines dkim-quoted-printable. Its 152 definition is modified in messages with internationalized header 153 fields so that non-ASCII UTF-8 characters need not be quoted. The 154 ABNF for dkim-safe-char in those messages is replaced by the 155 following, adding non-ASCII UTF-8 characters from [RFC3629]: 157 dkim-safe-char = %x21-3A / %x3C / %x3E-7E / 158 UTF8-2 / UTF8-3 / UTF8-4 159 ; '!' - ':', '<', '>' - '~', non-ASCII 161 UTF8-2 = 163 UTF8-3 = 165 UTF8-4 = 167 Section 3.5 of [RFC6376] states that IDNs in the d=, i=, and s= tags 168 of a DKIM-Signature header field MUST be encoded as A-labels. This 169 rule is relaxed only for internationalized messages header fields 170 [RFC6532] so IDNs SHOULD be represented as U-labels. This provides 171 improved consistency with other header fields. (A-labels remain 172 valid to allow a transition from older software.) The set of 173 allowable characters in the local-part of an i= tag is extended in 174 the same fashion as local parts of e-mail addresses as described in 175 section 3.2 of [RFC6532]. When computing or verifying the hash in a 176 DKIM signature as described in section 3.7, the hash MUST use the 177 domain name in the format it occurs in the header field. 179 Section 3.4.2 of [RFC6376] describes relaxed header canonicalization. 180 Its first step converts all header field names from upper case to 181 lower case. Field names are restricted to printable ASCII (see 182 [RFC5322] section 3.6.8) so this case conversion remains ASCII case 183 conversion. 185 DKIM key records, described in section 3.6.1, do not contain domain 186 names, so there is no change to their specification. 188 6. DMARC and internationalized mail 190 DMARC [RFC7489] defines a policy language that domain owners can 191 specify for the domain of the address in a RFC5322.From header field. 193 Section 6.6.1 specifies, somewhat imprecisely, how IDNs in the 194 RFC5322.From address domain are to be handled. That section is 195 updated to say that all U-labels in the domain are converted to 196 A-labels before further processing. Section 7.1 is similarly updated 197 to say that all U-labels in domains being handled are converted to 198 A-labels before further processing. 200 DMARC policy records, described in sections 6.3 and 7.1, can contain 201 e-mail addresses in the rua and ruf tags. Since a policy record can 202 be used for both internationalized and conventional mail, those 203 addresses still have to be conventional addresses, not 204 internationalized addresses. 206 7. IANA Considerations 208 This document makes no request of IANA. 210 8. Security Considerations 212 E-mail is subject to a vast range of threats and abuses. This 213 document attempts to slightly mitigate some of them but does not, as 214 far as the author knows, add any new ones. The updates to SPF, DKIM, 215 and DMARC are intended to allow the respective specifications work as 216 reliably on internationalized mail as they do on ASCII mail, so that 217 applications that use them, such as some kinds of spam and phish 218 filtering, can work more reliably on internationalized mail. 220 9. Normative References 222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 223 Requirement Levels", BCP 14, RFC 2119, 224 DOI 10.17487/RFC2119, March 1997, 225 . 227 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 228 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 229 2003, . 231 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 232 DOI 10.17487/RFC5322, October 2008, 233 . 235 [RFC5890] Klensin, J., "Internationalized Domain Names for 236 Applications (IDNA): Definitions and Document Framework", 237 RFC 5890, DOI 10.17487/RFC5890, August 2010, 238 . 240 [RFC5891] Klensin, J., "Internationalized Domain Names in 241 Applications (IDNA): Protocol", RFC 5891, 242 DOI 10.17487/RFC5891, August 2010, 243 . 245 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 246 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 247 RFC 6376, DOI 10.17487/RFC6376, September 2011, 248 . 250 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 251 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, 252 February 2012, . 254 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized 255 Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, 256 . 258 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 259 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 260 2012, . 262 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 263 Authorizing Use of Domains in Email, Version 1", RFC 7208, 264 DOI 10.17487/RFC7208, April 2014, 265 . 267 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 268 Message Authentication, Reporting, and Conformance 269 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 270 . 272 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 273 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 274 May 2017, . 276 Appendix A. Change history 278 05 to 06 more editorial nits 280 04 to 05 editorial nits 281 03 to 04 remove dangling A-R reference, add more i18nish and 282 security goodness 284 02 to 03 minor edits per Alexey 286 01 to 02 update references 288 00 to 01 Relaxed canon, Typos 290 00 First WG version 292 Author's Address 294 John Levine 295 Taughannock Networks 296 PO Box 727 297 Trumansburg, NY 14886 299 Email: standards@taugh.com 300 URI: http://jl.ly