Re: [dmarc-ietf] Eric Rescorla's No Objection on draft-ietf-dmarc-rfc7601bis-04: (with COMMENT)

"Murray S. Kucherawy" <superuser@gmail.com> Sun, 06 January 2019 02:21 UTC

Return-Path: <superuser@gmail.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 69D41130EE8; Sat, 5 Jan 2019 18:21:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 9e9rBOjQD9Nv; Sat, 5 Jan 2019 18:21:04 -0800 (PST)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2095012D4E7; Sat, 5 Jan 2019 18:21:01 -0800 (PST)
Received: by mail-lj1-x229.google.com with SMTP id c19-v6so35413265lja.5; Sat, 05 Jan 2019 18:21:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VqEKFCgw25hqkLLVnHKBLo/CW/BS8ZVbZnTn5Fcxpww=; b=mEPtEPU4fGkMEMNDLpl7cV4apO6ZW6KhSPNTJn5Q5AZEGWM5L+fPhNL47mhz9+pzZc nt6xf1jw64PFhov4reRKbSw2Imf3S4bOqk6ybW/nnLnQOaewm5BFCRm8saFgyqARxeq3 OiziEMTREix+eAUnhr5k+takFCqaA2qG66Yd/8Lw2lnklLhQwIFtDDZMfbfrnCOF/M1M WP66Yh2KPXCb87PIjV62o5UqAW6Gvn+tXW+Ly1I2mbE4MkODSjBV75LLTPzJcZaJcRZb 8a2faCOvDytTHjDQaygVIfRxOOf+yFrGXpL/c5o4gyodjKNrF0AGymm7lxEjc71KxKmT 1w0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VqEKFCgw25hqkLLVnHKBLo/CW/BS8ZVbZnTn5Fcxpww=; b=b4IP5rCviYFmHlmP4sh6ELoWPg6P1ppXbN7Lrhk7BPRHGQT2DXMzC65JF/HLdx/uua HRGpFXjQHNtc6+3pK70QjFgFfMTEUYEak/sonzoJ0GB8197axOTnQHB5Tiu83cRXumfc tHgjZTJtYwk8+kjCyqIQalBVRTwv4V0a3yrTISbJuN6brbR2EFQv5xMlm4VaIBlo4aCk 9y3MFMOdue9ZWChjSeT+fcP06FqiTQMYYN1YTZJUH4tfBlYGe+uASTd3jjQsOVgma8oH Xxqt9+4R+A8L+6qLf+QZWsUsDF81Nc65xOinfiM97QQptIzuD3KsuEKQAEHbm09q+aZt F4lg==
X-Gm-Message-State: AJcUukcz/LXqt5cRSUyxuV3uETGBo+YqcKFh1vq+YeXkcFT9a0UJPhb7 FQDGTjjIxrkCDWxXwl0xSRTZbNUwsosy1XJHNkw=
X-Google-Smtp-Source: ALg8bN7QETYHJj9pLXeP2KzQ3+GpBxwBJdJNhqZMvVDFOWdhwe2UH9nbn/fxcgTN+7DwluWRfDc1Bkj1LgePBX7iRsI=
X-Received: by 2002:a2e:750a:: with SMTP id q10-v6mr28046657ljc.39.1546741258798; Sat, 05 Jan 2019 18:20:58 -0800 (PST)
MIME-Version: 1.0
References: <154276121031.29824.13392388978609143158.idtracker@ietfa.amsl.com>
In-Reply-To: <154276121031.29824.13392388978609143158.idtracker@ietfa.amsl.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Sat, 5 Jan 2019 18:20:47 -0800
Message-ID: <CAL0qLwbo6Obzq7d4c=tzBJi61-1RPb6UO8KKkwmex=GV7zf7PA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: The IESG <iesg@ietf.org>, Tim Draegen <tim@dmarcian.com>, IETF DMARC WG <dmarc@ietf.org>, draft-ietf-dmarc-rfc7601bis@ietf.org, dmarc-chairs@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004a560d057ec0c34a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/nkeYwNySeJeTOvDMPgucAHYQ2Tk>
Subject: Re: [dmarc-ietf] Eric Rescorla's No Objection on draft-ietf-dmarc-rfc7601bis-04: (with 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: Sun, 06 Jan 2019 02:21:07 -0000

Hi Eric, thanks for your comments and sorry for the delay in replying.

I've applied all of your comments except those below, for discussion:

On Tue, Nov 20, 2018 at 4:46 PM Eric Rescorla <ekr@rtfm.com> wrote:

>
> IMPORTANT
> S 7.10.
> >      processing of these is outside of the intended scope of this
> document
> >      (see Section 1.3), some early guidance to MUA developers is
> >      appropriate here.
> >
> >      Since MTAs are unlikely to strip Authentication-Results header
> fields
> >      after mailbox delivery, MUAs are advised in Section 4.1 to ignore
>
> I think you want to be stronger than "are advised to"
>

I changed "advised" to "warned"; is that adequate?  It's referring to a
SHOULD in 4.1.

S 1.2.
> >      Thus, this document defines a "trust boundary" as the delineation
> >      between "external" and "internal" entities.  Services that are
> >      internal -- within the trust boundary -- are provided by the ADMD's
> >      infrastructure for its users.  Those that are external are outside
> of
> >      the authority of the ADMD.  By this definition, hosts that are
> within
> >      a trust boundary are subject to the ADMD's authority and policies,
>
> This seems like a reasonable design, but not the only one. For
> instance, Gmail might attach these headers, but I don't think of my
> MUA as being subject to its authority and policies.
>

The MUA in the Gmail case is Gmail itself, isn't it?  Or at least their
client?  Or are you referring to some IMAP access to it?

S 1.5.3.
> >      agents, assign (some) responsibility for the message (which implies
> >      authorization), and ensure that the listed portions of the message
> >      were not modified in transit.  Since the signatures are not tied to
> >      SMTP connections, they can be added by either the ADMD of origin,
> >      intermediate ADMDs (such as a mailing list server), other handling
> >      agents, or any combination.
>
> I'm not sure how persuaded I am by this terminology. However,
> regardless of that, this claim about SPF seems problematic in the
> sense that you could have an intermediate MTA decorate the message
> with the incoming IP address (in some unspecified way)  but then have
> the terminal MTA do the SPF validation.
>

Right, that's a property of SPF: It only evaluates the latest ("connecting"
in that paragraph) hop, while DKIM often survives end-to-end irrespective
of who's relaying it in to the local ADMD.

S 2.2.
> >      combination of these can be applied.
> >
> >   2.2.  Formal Definition
> >
> >      Formally, the header field is specified as follows using Augmented
> >      Backus-Naur Form ([ABNF]):
>
> An example would be kind of helpful here.
>

I put in a forward reference to the Examples section instead.

S 2.4.
> >
> >      This ptype existed in the original specification for this header
> >      field, but without a complete description or example of intended
> use.
> >      As a result, it has not seen any practical use to date that matches
> >      its intended purpose.  These added details are provided to guide
> >      implementers toward proper use.
>
> This text is odd in a bis draft, because "the original" is not 7601 or
> 7001.
>

Would actual RFC numbers be better?  The point here is that the original
(5451) didn't do a great job of explaining how this works, and then the
intervening versions (7001, 7601) didn't fix it.  We're finally fixing it
here.

-MSK