Skip to main content

Email Authentication for Internationalized Mail
draft-ietf-dmarc-eaiauth-06

Yes

(Alexey Melnikov)

No Objection

Warren Kumari
(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Ignas Bagdonas)
(Magnus Westerlund)
(Martin Vigoureux)
(Mirja Kühlewind)
(Suresh Krishnan)

Note: This ballot was opened for revision 04 and is now closed.

Roman Danyliw
No Objection
Comment (2019-04-09 for -05) Sent
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.
Warren Kumari
No Objection
Éric Vyncke
No Objection
Comment (2019-04-04 for -04) Sent
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.
Adam Roach Former IESG member
Yes
Yes (2019-04-09 for -05) Sent
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."
Alexey Melnikov Former IESG member
Yes
Yes (for -04) Unknown

                            
Barry Leiba Former IESG member
(was No Objection) Yes
Yes (2019-04-07 for -05) Sent for earlier
— 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.
Alissa Cooper Former IESG member
No Objection
No Objection (for -05) Not sent

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -05) Not sent

                            
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2019-04-17) Sent
Thank you for resolving my Discuss point!
Deborah Brungard Former IESG member
No Objection
No Objection (for -05) Not sent

                            
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -05) Not sent

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (for -05) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -05) Not sent

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -04) Not sent

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -05) Not sent