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

"John R Levine" <johnl@taugh.com> Fri, 05 April 2019 17:50 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF2212012F for <dmarc@ietfa.amsl.com>; Fri, 5 Apr 2019 10:50:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=lKGwpLmt; dkim=pass (1536-bit key) header.d=taugh.com header.b=R+ECEL72
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eqo88iRVa7Fp for <dmarc@ietfa.amsl.com>; Fri, 5 Apr 2019 10:50:19 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0B4E12008B for <dmarc@ietf.org>; Fri, 5 Apr 2019 10:50:18 -0700 (PDT)
Received: (qmail 64796 invoked from network); 5 Apr 2019 17:50:16 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=fd19.5ca79558.k1904; bh=yBMYXvU7L9BKmQtjOrB1C127FCqksOFcRYXDnrWRPfs=; b=lKGwpLmtfEbiRw/oEZ4esH6zmj0ZbFDAohFraWlMffbkzetmzNnK5mWMu7NtB4OnAm2rTPbj/AvB0ZZUZAESt8sZ36eskTD6KFjRbhLtKBglR04gke8Vy0oNzRlcbO7fe3M4rZp/9Ng44xr48iCFzmtoYbrub4QGZFLLEAgFyQaolsrfVahJpvbnWnWQyknlQCpKNFEFYbz/3Om9oI43YniByejhzcY4QA1mMzFhmk4PuT+dq2kIMj0d24C3Q+gA
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=fd19.5ca79558.k1904; bh=yBMYXvU7L9BKmQtjOrB1C127FCqksOFcRYXDnrWRPfs=; b=R+ECEL72xikFULO6n25+FvOtJnQV4LVsFIWSOK4YfaUv2Kdtf95xFhucmqIyAPTNt6d7150MREUAl1tNk5NKYK262m8vZFr9tVuSHnPEsWqBtBp8NIoo0MkvQ2H6n943O0/C4BD3Kd5bFC4s0FAJLjIemlIRMbEP/HmMeYdvCMEtZzDVBFTtyu06KvEhp8aaD/gSopQnbPWntsgLTuLYG88boKpjRoqJ755KWhdYP8PFwvC7YP9K9km2E1c24WJU
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 05 Apr 2019 17:50:15 -0000
Date: 5 Apr 2019 13:50:15 -0400
Message-ID: <alpine.OSX.2.21.1904051336300.4382@ary.qy>
From: "John R Levine" <johnl@taugh.com>
To: "Benjamin Kaduk" <kaduk@mit.edu>
Cc: "The IESG" <iesg@ietf.org>, dmarc-chairs@ietf.org, "Kurt Andersen" <kurta@drkurt.com>, dmarc@ietf.org
In-Reply-To: <155448515761.10017.3964878632140323988.idtracker@ietfa.amsl.com>
References: <155448515761.10017.3964878632140323988.idtracker@ietfa.amsl.com>
User-Agent: Alpine 2.21 (OSX 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/Q2Srklc0hLaBvUPP2GWgbHyaewI>
Subject: Re: [dmarc-ietf] [taugh.com-standards] 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
Precedence: list
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:50:23 -0000

On Fri, 5 Apr 2019, Benjamin Kaduk via Datatracker wrote:
> 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?

Approximately nobody uses those macros even for ASCII addresses.  SPF 
lists a set of things to allow, not to forbid, so that the most that will 
happen is that an address won't authenticate.

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

There are a fair number of people in the WG who implement this stuff and 
nobody has said it's hard to follow.  I'm not inclined to add verbiage 
just for the sake of doing so.

> 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?

Yes.

> RFC 6532 does not mention an "i=" tag anywhere, ...

I suppose I could say "as in the description of local parts of e-mail 
addresses as in RFC 6532"

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

No more than there has been all along.  Intermediaries can do all sorts of 
bad stuff to mail messages althrough for the most part they don't.

>   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?

Good catch, the ref to 6.7 is left over from an earlier version where this 
draft also updated the Authentication-Results spec.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly