[dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-eaiauth-05: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 11 April 2019 17:56 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 8045D120106; Thu, 11 Apr 2019 10:56:18 -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.95.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <155500537851.14222.14675803011447947339.idtracker@ietfa.amsl.com>
Date: Thu, 11 Apr 2019 10:56:18 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/nNgWHcrJ68CKazaQSPJpN5FTpPg>
Subject: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-eaiauth-05: (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: Thu, 11 Apr 2019 17:56:19 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-dmarc-eaiauth-05: 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 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] ---------------------------------------------------------------------- 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.)
- [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk via Datatracker