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

ned+dmarc@mrochek.com Sun, 06 January 2019 19:10 UTC

Return-Path: <ned+dmarc@mrochek.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 AA66712D4F0 for <dmarc@ietfa.amsl.com>; Sun, 6 Jan 2019 11:10:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.207
X-Spam-Level:
X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 XBVV8MMfm_MX for <dmarc@ietfa.amsl.com>; Sun, 6 Jan 2019 11:10:04 -0800 (PST)
Received: from mauve.mrochek.com (unknown [66.159.242.17]) (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 AFED912D4EF for <dmarc@ietf.org>; Sun, 6 Jan 2019 11:10:03 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1OU133R2O00D6XF@mauve.mrochek.com> for dmarc@ietf.org; Sun, 6 Jan 2019 11:05:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1546801499; bh=pCas/9NYJ0VDOWbaHrjnbipgZLmrlQigFC/CJPT0/lk=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=Ur+E9C8Riov742N22ol9CQ6MtJ6Y8cv+uaBcCOx0R4s1XASqk9DjkXJCHc+o5UZSL paA+L3LgkIFAsUuelaphXIYwWdFYiFUo04ecT8BpmM1zBe8JsUy4Er8d4725n/yFxb ju7KKVp0QPALFId/GQ+xzpdsOWf/ABA6hfx4I2k4=
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1N39ADWKW00004L@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Sun, 6 Jan 2019 11:04:55 -0800 (PST)
From: ned+dmarc@mrochek.com
Cc: "Murray S. Kucherawy" <superuser@gmail.com>, Tim Draegen <tim@dmarcian.com>, IETF DMARC WG <dmarc@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-dmarc-rfc7601bis@ietf.org, dmarc-chairs@ietf.org
Message-id: <01R1OU11IFIK00004L@mauve.mrochek.com>
Date: Sun, 06 Jan 2019 10:29:31 -0800 (PST)
In-reply-to: "Your message dated Sun, 06 Jan 2019 08:42:42 -0800" <CABcZeBPbEd6hRyzJv9JP-NwiTZG_VtEQ+Y2osyorkC4B-q7-4A@mail.gmail.com>
References: <154276121031.29824.13392388978609143158.idtracker@ietfa.amsl.com> <CAL0qLwbo6Obzq7d4c=tzBJi61-1RPb6UO8KKkwmex=GV7zf7PA@mail.gmail.com> <CABcZeBPbEd6hRyzJv9JP-NwiTZG_VtEQ+Y2osyorkC4B-q7-4A@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/i46OpwpLlBo3HbSBsHCUyRnCLu8>
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 19:10:06 -0000

> On Sat, Jan 5, 2019 at 6:20 PM Murray S. Kucherawy <superuser@gmail.com>
> wrote:

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

This sentence seems nonsensical to me: A message that has undergone
delivery is by definition out of the MTA's hands - this is an essential
part of delivery semantics.

Now, if you're talking about what MTAs do before, as opposed to after,
delivery, or submitting a previously delivered messge, or submitting a message
part from a previously delivered message, or submitting a new message
containing content extracted from a previously delivered message, then you need
to be clear that's what you mean. But in the submission cases I'll note that
it's not unlikely that Authentication-Results fields at the top of such a
message will be removed by the submission process.

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

> What I am thinking is that this should be normative language.

Whereas I'm thinking that this is poor advice in general and should either be
more tightly qualified or removed.

The problem is that there are many different reasons for exacting an
encapsulated message, and the optimum handling of header fields varies
dependin on the reason.

If the intention is, say, to "burst" a mailing list digest into its component
messages, since these fields cannot be asumed to have been
generated by a trusted agent, whereas top-level Authentication-Results: fields
may have some trust associated with them, then by all means remove the fields.

However, if the digest was constucted from previously delivered messages
with trusted Authentication-Results fields, retaining them is OK and may
even be of value.

And if the the intent is to use the messages as input to some sort of security
scanning process, removing them may actually have an adverse effect.

There are undoubtedly many other cases that arise, but I think this
demonstrates the point.

Of course having a simple rule would be nice. But there's no simple rule
for deciding where the boundary between trusted and untrusted Received:
fields lies - something which already complicates the handling of extracted
messages - and we manage to deal with that all the time.

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

> Yes. Like what I have on my phone.

Indeed. IMAP and POP in the MSP case are a bit at odds with the simple
ADMD model. That said, I'm not entirely sure what can be done about it
that will clarify rather than further obscure the picture.

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

> Hmm.. I think I'm making a different argument here. If the evaluating ADMD
> trust claims made by a relaying hop, then it is able to do its own SPF
> evaluation by having the relaying hop supply the IP address of the
> originating MTA, even if the relaying hop didn't itself do SPF validation.
> In this sense, it's not tied to the incoming connection.

Quite right. And these sorts of arrangements where IP address information
is derived not from the connection but from a Received: field, XCLIENT
command, etc. are actually pretty common.

				Ned