[dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-eaiauth-04: (with DISCUSS and COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Fri, 05 April 2019 17:25 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dmarc@ietf.org
Delivered-To: dmarc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 986C81200B9; Fri, 5 Apr 2019 10:25:57 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-dmarc-eaiauth@ietf.org, dmarc-chairs@ietf.org, kurta@drkurt.com, dmarc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <155448515761.10017.3964878632140323988.idtracker@ietfa.amsl.com>
Date: Fri, 05 Apr 2019 10:25:57 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/vRZonXlrWqtdD73Xq1XBhPZA-QY>
Subject: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-eaiauth-04: (with DISCUSS and COMMENT)
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Apr 2019 17:25:58 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dmarc-eaiauth-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-eaiauth/



----------------------------------------------------------------------
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).


----------------------------------------------------------------------
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.)