Email Authentication for Internationalized Mail
RFC 8616

Received changes through RFC Editor sync (created alias RFC 8616, changed title to 'Email Authentication for Internationalized Mail', changed abstract to 'Sender Policy Framework (SPF) (RFC 7208), DomainKeys Identified Mail (DKIM) (RFC 6376), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) (RFC 7489) enable a domain owner to publish email authentication and policy information in the DNS.  In internationalized email, domain names can occur both as U-labels and A-labels.  This specification updates the SPF, DKIM, and DMARC specifications to clarify which form of internationalized domain names to use in those specifications.', changed pages to 6, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2019-06-30, changed IESG state to RFC Published, created updates relation between draft-ietf-dmarc-eaiauth and RFC 6376, created updates relation between draft-ietf-dmarc-eaiauth and RFC 7208, created updates relation between draft-ietf-dmarc-eaiauth and RFC 7489)

[Ballot discuss]
Thanks for this document; it's good to improve the clarity and precision
of how various pieces of the ecosystem interact.  That said, I do have an
issue that needs to be addressed prior to publication:

We need to properly document the consequences of causing the %{s} and
%{l} macros to never match when the local-part contains non-ASCII characters.
I understand that they are quite rare in practice, and this rarity justifies not
going to great lengths to provide a technical solution, but that doesn't mean
that we can silently ignore the issues.

[discussion of specificity of Updates  removed, as the discussion happened]

[Ballot comment]

Section 3

  In headers in EAI mail messages, domain names that were restricted to
  ASCII can now be U-labels, and mailbox local parts can be UTF-8.

nit: "can now" implies some previous baseline state, but that reference
for comparison is not especially clear just from context.

Section 5

I'm having a hard time following this paragraph:

  Section 3.5 of [RFC6376] states that IDNs in the d=, i=, and s= tags
  of a DKIM-Signature header MUST be encoded as A-labels.  This rule is
  relaxed only for internationalized messages headers [RFC6532] so IDNs
  SHOULD be represented as U-labels but MAY be A-labels.  This provides
  improved consistency with other headers.  The set of allowable
  characters in the local-part of an i= tag is extended as described in
  [RFC6532].  When computing or verifying the hash in a DKIM signature
  as described in section 3.7, the hash MUST use the domain name in the
  format it occurs in the header.

Is "this rule is relaxed" a new policy as of this document?  RFC 6532
does not mention an "i=" tag anywhere, so I feel like we may need
greater detail on what behavior from 6532 we're pulling in.  (Are we
just intending to add the UTF8-non-ascii block as valid ABNF for the RHS
of the "i=" tag?)

Is there any risk that an intermediary will reencode the domain name and
cause the signature validation to fail?

Section 6

  Section 6.6.1 specifies, somewhat imprecisely, how IDNs in the
  RFC5322.From address domain are to be handled.  [...]

A bare "Section 6.6.1" normally refers to the current document, so
repeating RFC 7489 is probably in order.

(Same for the other Section references in this section.)

Section 8

(Depending on how the first DISCUSS point is resolved, we may be adding
some new threats that need to be covered.)

[Ballot comment]
Thanks to everyone who worked on this document.

---------------------------------------------------------------------------

The i18ndir review included a number of minor issues that appear to remain
unaddressed. (To be clear, I don't assert that all of them require document
changes, but I would expect to see responses to the reviewer on these points).
I reiterate one of the more important minor comments below.

---------------------------------------------------------------------------

I agree with Benjamin's DISCUSS comment: this document needs to better
explain the consequences of the inability to match %{s} and %{l}. He talks about
it from a security perspective, but I think there's also a discussion to be had
here about whether this disadvantages users who elect to have non-ASCII
characters in their mailbox names.

I did see the response to the i18ndir review regarding the low usage of these
macros. If that is relevant to the decision to ignore the proper functioning of
these macros, then such rationale should be included in this document. Further,
if this document is breaking these macros under certain circumstances due to low
deployment, I would urge the working group to consider whether this document
should formally deprecate their use rather than relegating certain users to
second-class status.

---------------------------------------------------------------------------

§1:

>  the From: header of e-mail messages.

Nit: "...header field..."

---------------------------------------------------------------------------
§5:

>  Section 2.11 of [RFC6376] defines dkim-quoted-printable.  Its
>  definition is modified in messages with internationalized headers so
>  that non-ASCII UTF-8 characters need not be quoted.  The ABNF for
>  dkim-safe-char in those messages is replaced by the following, adding
>  non-ASCII UTF-8 characters from [RFC3629]:

Nit (twice): replace "UTF-8 characters" with either "UTF-8 byte sequences" or
"UTF-8 encoded Unicode characters".

---------------------------------------------------------------------------

§3:

>  Header names and other text intended primarily to be interpreted by

Nit: "Header field names..."

---------------------------------------------------------------------------

§5:

>  DKIM [RFC6376] specifies a message header that contains a

Nit: "...header field..."

>  of a DKIM-Signature header MUST be encoded as A-labels.  This rule is

Nit: "...header field..."

>  consistency with other headers.  (A-labels remain valid to allow a

Nit: "...header fields..."

>  in section 3.7, the hash MUST use the domain name in the format it
>  occurs in the header.

Nit: "...header field."

[Ballot comment]
Thanks for the clarifications this draft provides to deployed technologies.  A few comments:

(1) Support Ben’s first DISCUSS asking questions about macro expansion

(2) A process question – are there any issues with a IETF stream proposed standard draft (this draft) updating an ISE stream published document (RFC7489)?

(3) Section 3, Please expand “EAI” on first use.  It isn’t in the RFC Editor Abbreviations List -- https://www.rfc-editor.org/materials/abbrev.expansion.txt

(4) Section 4 says, “Since the EHLO command precedes the server response that tells whether the server supports the SMTPUTF8 extension , an IDN argument  MUST be represented as an A-label.”  Is the “IDN argument” in question the hostname used in the EHLO?  If this is the only argument, I would recommend explicitly saying s/an IDN argument/an IDN hostname used in EHLO/).

(5) Section 6, Recommend making the reference clearer by
s/described in section 7/described in section 7.1 of [RFC7208]/

(6) Section 5, Recommend making the reference clearer by
s/When computing or verifying the hash in a DKIM signature as described in section 3.7/
When computing or verifying the hash in a DKIM signature as described in section 3.7 [RFC6376]/

(7) Section 6, Recommend making the reference clearer by
s/Section 6.6.1  specifies/Section 6.6.1 of [RFC7489]/
s/Sections 6.7 and 7.1/Sections 6.7 and 7.1 of [RFC7489]/

(8) Section 6 says “Section 6.6.1  specifies, somewhat imprecisely”.  What does the “somewhat” mean?  I recommend more precision in describing the ambiguity left by RFC7489 or dropping that word.

(9) Section 8.  Recommend making more specific statements about the Security Considerations:

s/This document attempts  to slightly mitigate some of them but does not, as far as the author knows, add any new ones. /
This document provides clarifications to existing protocols to improve their handling of internationalized email./ 

Recommend adding something as follows as the last sentence: “It introduces no additional security considerations beyond those already identified in the base specifications of [RFC7208], [RFC6376] and [RFC7489].” – pending resolution of Ben’s first DISCUSS.

[Ballot comment]
— Section 4 —

  An IDN in MAIL FROM can
  be either U-labels or A-labels.

There’s a number agreement error here.  Make it “...can use...,” (or “can include”) and I think that fixes it.

[Ballot discuss]
Thanks for this document; it's good to improve the clarity and precision
of how various pieces of the ecosystem interact.  That said, I do have a
couple of potential issues that need to be addressed prior to
publication:

I'm not sure I fully understand the security consequences of causing
the SPF macros %{s} and %{l} to never match when the local-part contains
non-ASCII characters, but they seem potentially quite bad.  That is, if
the policy is intending to limit allowed senders to a specific list (or
block specific senders), would an attacker be able to avoid the
restriction by using a non-ASCII local-part?

I'd also like to discuss whether we need greater specificity in the
nature of the updates applied to the Updates:'d documents.  For example,
Section 6 (of this document) says that Xection X [of RFC7489] is updated
"to say that all U-labels in domains are converted to A-labels before
further processing", but most of those referenced sections contain
step-by-step listings of a procedure to follow.  It doesn't seem like
much of a burden for us to say "between steps X and X+1, insert the
following step: "[convert domain from U-label to A-label]", and that has
a potentially significant gain in clarity to the reader (and thus,
interoperability).

[Ballot comment]
Section 2

That's not the actual boilerplate text from RFC8174; please just
copy/paste the appropriate snippet.

Section 3

  In headers in EAI mail messages, domain names that were restricted to
  ASCII can now be U-labels, and mailbox local parts can be UTF-8.

nit: "can now" implies some previous baseline state, but that reference
for comparison is not especially clear just from context.

Section 5

I'm having a hard time following this paragraph:

  Section 3.5 of [RFC6376] states that IDNs in the d=, i=, and s= tags
  of a DKIM-Signature header MUST be encoded as A-labels.  This rule is
  relaxed only for internationalized messages headers [RFC6532] so IDNs
  SHOULD be represented as U-labels but MAY be A-labels.  This provides
  improved consistency with other headers.  The set of allowable
  characters in the local-part of an i= tag is extended as described in
  [RFC6532].  When computing or verifying the hash in a DKIM signature
  as described in section 3.7, the hash MUST use the domain name in the
  format it occurs in the header.

Is "this rule is relaxed" a new policy as of this document?  RFC 6532
does not mention an "i=" tag anywhere, so I feel like we may need
greater detail on what behavior from 6532 we're pulling in.  (Are we
just intending to add the UTF8-non-ascii block as valid ABNF for the RHS
of the "i=" tag?)

Is there any risk that an intermediary will reencode the domain name and
cause the signature validation to fail?

Section 6

  DMARC [RFC7489] defines a policy language that domain owners can
  specify for the domain of the address in a RFC5322.From header.

nit: the formatting looks weird

  Section 6.6.1 specifies, somewhat imprecisely, how IDNs in the
  RFC5322.From address domain are to be handled.  [...]

(ditto)
Also, a bare "Section 6.6.1" normally refers to the current document, so
repeating RFC 7489 is probably in order.

(Same for the other Section references in this section.)

  A-labels before further processing.  Sections 6.7 and 7.1 are
  similarly updated to say that all U-labels in domains being handled
  are converted to A-labels before further processing.

I don't really see a procedural listing described in Section 6.7 of RFC
7489; can you point me to where this conversion to A-labels is supposed
to happen?

Section 8

(Depending on how the first DISCUSS point is resolved, we may be adding
some new threats that need to be covered.)

[Ballot comment]
Does -04 fix all issues / comments from the Internationalization directorate (which was about -03) ?

Nits: section 8 in security consideration, unsure whether the use of "as far as the author knows" is useful or required.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-dmarc-eaiauth-03, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-03-14):

From: The IESG
To: IETF-Announce
CC: alexey.melnikov@isode.com, dmarc@ietf.org, kurta@drkurt.com, draft-ietf-dmarc-eaiauth@ietf.org, dmarc-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (E-mail Authentication for Internationalized Mail) to Proposed Standard


The IESG has received a request from the Domain-based Message Authentication,
Reporting & Conformance WG (dmarc) to consider the following document: -
'E-mail Authentication for Internationalized Mail'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-03-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  SPF (RFC7208), DKIM (RFC6376), and DMARC (RFC7489) enable a domain
  owner to publish e-mail authentication and policy information in the
  DNS.  In internationalized e-mail, domain names can occur both as
  U-labels and A-labels.  The Authentication-Results header reports the
  result of authentication checks made with SPF, DKIM, DMARC, and other
  schemes.  This specification updates the SPF, DKIM, and DMARC
  specifications to clarify which form of internationalized domain
  names to use in those specifications, and when creating
  Authentication-Results headers.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dmarc-eaiauth/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dmarc-eaiauth/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (Informational - Independent Submission Editor stream)

This RFC is being put forward as a proposed standard, updating three prior standards and one prior informational specification.

Technical Summary:

    E-Mail Authentication for Internationalized Mail updates the pre-EAI
    authentication mechanisms: SPF, DKIM, and DMARC by clarifying which form
    of the internationalized domain names (IDNs) to use in those protocols
    and when recording results in the Authentication-Results header.

Working Group Summary:

    The working group process has not had any controversy regarding this
    specification as it is viewed primarily as clarifying existing practice.
    Two other documents from the working group are referencing this document
    for their treatment of IDNs in the context of the ARC and 7601bis update
    to the Authentication-Results header syntax.

Document Quality:

    This document covers the implications for all four of the referenced
    specifications. It includes a normative reference to an informative
    specification (RFC7489) because of the mixture between standards
    track and informative amongst the updated specs.

Personnel:

    Document Shepherd: Kurt Andersen
    Area Director:  Alexey Melnikov

Responding to the other identified questions for shepherd review:

(3) The document has been reviewed and subjected to extra verbose nit analysis.
The document has completed last call review within the DMARC working group and
no issues were identified.

(4) I have no concerns about the depth or breadth of the reviews that have been
performed.

(5) No additional reviews should be needed since this document is enumerating
clarifications between the email address internationalization specs and
pre-existing email domain authentication specifications.

(6) No concerns other than the downref citation against RFC7489.

(7 & 8) The author has confirmed IPR compliance.

(9) As noted above in the summary, there is no controversy regarding this
document. General consensus exists amongst the WG. There has been
minimal discussion because the draft has existed for quite some time before
being adopted by the WG and the work is straightforward.

(10) No appeals or discontent has been expressed.

(11) Aside from the nits tool being overly picky about connjunctions within
the boilerplate section, and the indicated downref, no other nits exist.

(12) N/A

(13) yes

(14) no

(15) Yes - normative reference against RFC7489

(16) This document updates three other RFCs (6376, 7208, 7489). There are descriptive
references to the Authentication-Results header (currently defined in 7601) but that
RFC is currently being obsoleted by draft-ietf-dmarc-rfc7601bis which also incorporates
the information found in this document.

(17) N/A

(18) N/A

(19) N/A

This RFC is being put forward as a proposed standard, updating three prior standards and one prior informational specification.

Technical Summary:

    E-Mail Authentication for Internationalized Mail updates the pre-EAI
    authentication mechanisms: SPF, DKIM, and DMARC by clarifying which form
    of the internationalized domain names (IDNs) to use in those protocols
    and when recording results in the Authentication-Results header.

Working Group Summary:

    The working group process has not had any controversy regarding this
    specification as it is viewed primarily as clarifying existing practice.
    Two other documents from the working group are referencing this document
    for their treatment of IDNs in the context of the ARC and 7601bis update
    to the Authentication-Results header syntax.

Document Quality:

    This document covers the implications for all four of the referenced
    specifications. It includes a normative reference to an informative
    specification (RFC7489) because of the mixture between standards
    track and informative amongst the updated specs.

Personnel:

    Document Shepherd: Kurt Andersen
    Area Director:  Alexey Melnikov

Responding to the other identified questions for shepherd review:

(3) The document has been reviewed and subjected to extra verbose nit analysis.
The document has completed last call review within the DMARC working group and
no issues were identified.

(4) I have no concerns about the depth or breadth of the reviews that have been
performed.

(5) No additional reviews should be needed since this document is enumerating
clarifications between the email address internationalization specs and
pre-existing email domain authentication specifications.

(6) No concerns other than the downref citation against RFC7489.

(7 & 8) The author has confirmed IPR compliance.

(9) As noted above in the summary, there is no controversy regarding this
document. General consensus exists amongst the WG. There has been
minimal discussion because the draft has existed for quite some time before
being adopted by the WG and the work is straightforward.

(10) No appeals or discontent has been expressed.

(11) Aside from the nits tool being overly picky about connjunctions within
the boilerplate section, and the indicated downref, no other nits exist.

(12) N/A

(13) yes

(14) no

(15) Yes - normative reference against RFC7489

(16) This document updates four other RFCs (6376, 7208,
7489 and 7601). 7601 is currently being obsoleted by draft-ietf-dmarc-rfc7601bis.
With the exception of 7601, they are cited in the abstract and throughout the document.

(17) N/A

(18) N/A

(19) N/A

This RFC is being put forward as a proposed standard, updating three prior standards and one prior informational specification.

Technical Summary:

    E-Mail Authentication for Internationalized Mail updates the pre-EAI
    authentication mechanisms: SPF, DKIM, and DMARC by clarifying which form
    of the internationalized domain names (IDNs) to use in those protocols
    and when recording results in the Authentication-Results header.

Working Group Summary:

    The working group process has not had any controversy regarding this
    specification as it is viewed primarily as clarifying existing practice.
    Two other documents from the working group are referencing this document
    for their treatment of IDNs in the context of the ARC and 7601bis update
    to the Authentication-Results header syntax.

Document Quality:

    This document covers the implications for all four of the referenced
    specifications. It includes a normative reference to an informative
    specification (RFC7489) because of the mixture between standards
    track and informative amongst the updated specs.

Personnel:

    Document Shepherd: Kurt Andersen
    Area Director:  Alexey Melnikov

Responding to the other identified questions for shepherd review:

(3) The document has been reviewed and subjected to extra verbose nit analysis.
The document has completed last call review within the DMARC working group and
no issues were identified.

(4) I have no concerns about the depth or breadth of the reviews that have been
performed.

(5) No additional reviews should be needed since this document is enumerating
clarifications between the email address internationalization specs and
pre-existing email domain authentication specifications.

(6) No concerns other than the downref citation against RFC7489.

(7 & 8) The author has confirmed IPR compliance.

(9) As noted above in the summary, there is no controversy regarding this
document. General consensus exists amongst the WG.

(10) No appeals or discontent has been expressed.

(11) Aside from the nits tool being overly picky about connjunctions within
the boilerplate section, and the indicated downref, no other nits exist.

(12) N/A

(13) yes

(14) no

(15) Yes - normative reference against RFC7489

(16) This document updates four other RFCs (6376, 7208,
7489 and 7601). 7601 is currently being obsoleted by draft-ietf-dmarc-rfc7601bis.
With the exception of 7601, they are cited in the abstract and throughout the document.

(17) N/A

(18) N/A

(19) N/A

This RFC is being put forward as a proposed standard, updating three prior standards and one prior informational specification.

Technical Summary:

    E-Mail Authentication for Internationalized Mail updates the pre-EAI
    authentication mechanisms: SPF, DKIM, and DMARC by clarifying which form
    of the internationalized domain names (IDNs) to use in those protocols
    and when recording results in the Authentication-Results header.

Working Group Summary:

    The working group process has not had any controversy regarding this
    specification as it is viewed primarily as clarifying existing practice.
    Two other documents from the working group are referencing this document
    for their treatment of IDNs in the context of the ARC and 7601bis update
    to the Authentication-Results header syntax.

Document Quality:

    This document covers the implications for all four of the referenced
    specifications. It includes a normative reference to an informative
    specification (RFC7489) because of the mixture between standards
    track and informative amongst the updated specs.

Personnel:

    Document Shepherd: Kurt Andersen
    Area Director:  Alexey Melnikov

Responding to the other identified questions for shepherd review:

(3) The document has been reviewed and subjected to extra verbose nit analysis.
The document has completed last call review within the DMARC working group and
no issues were identified.

(4) I have no concerns about the depth or breadth of the reviews that have been
performed.

(5) No additional reviews should be needed since this document is enumerating
clarifications between the email address internationalization specs and
pre-existing email domain authentication specifications.

(6) No concerns other than the downref citation against RFC7489.

(7 & 8) The author has confirmed IPR compliance.

(9) As noted above in the summary, there is no controversy regarding this
document. General consensus exists amongst the WG.

(10) No appeals or discontent has been expressed.

(11) Aside from the nits tool being overly picky about connjunctions within
the boilerplate section, and the indicated downref, no other nits exist.

(12) N/A

(13) yes

(14) no

(15) Yes - normative reference against RFC7489

(16) This document updates four other RFCs (one of which is currently in a bis
- obsoletes state). They are cited in the abstract and throughout the document.

(17) N/A

(18) N/A

(19) N/A

This RFC is being put forward as a proposed standard, updating three prior standards and one prior informational specification.

Technical Summary:

    E-Mail Authentication for Internationalized Mail updates the pre-EAI
    authentication mechanisms: SPF, DKIM, and DMARC by clarifying which form
    of the internationalized domain names (IDNs) to use in those protocols
    and when recording results in the Authentication-Results header.

Working Group Summary:

    The working group process has not had any controversy regarding this
    specification as it is viewed primarily as clarifying existing practice.
    Two other documents from the working group are referencing this document
    for their treatment of IDNs in the context of the ARC and 7601bis update
    to the Authentication-Results header syntax.

Document Quality:

    This document covers the implications for all four of the referenced
    specifications. It includes a normative reference to an informative
    specification (RFC7489) because of the mixture between standards
    track and informative amongst the updated specs.

Personnel:

    Document Shepherd: Kurt Andersen
    Area Director:  Alexey Melnikov