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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 5 Jan 2019 18:20:47 -0800

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 <[email-masked]> 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

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 6 Jan 2019 08:42:42 -0800

> I changed "advised" to "warned"; is that adequate?  It's referring to a

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

> client?  Or are you referring to some IMAP access to it?

Yes. Like what I have on my phone.

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

S 2.2.
> intervening versions (7001, 7601) didn't fix it.  We're finally fixing it

Yeah, I think RFC #s would be better...

-Ekr

---

From: [email-masked]
Date: Sun, 06 Jan 2019 10:29:31 -0800 (PST)

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

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

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

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 6 Jan 2019 12:13:17 -0800

> more tightly qualified or removed.

I could also live with that. I don't really have a substantive opinion here
about this
advice, I'm just trying to avoid having language which sort of exhorts
people
do to things, but not really.

-Ekr