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

[Eric Rescorla <[e-mail]>]

On Sun, Jan 6, 2019 at 11:10 AM Ned Freed <[e-mail]> wrote:

> > On Sat, Jan 5, 2019 at 6:20 PM Murray S. Kucherawy <[e-mail]>
> > 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 <[e-mail]> 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.
>

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


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