Re: [dmarc-ietf] Alternative draft text for draft-ietf-dmarc-arc-protocol

["Murray S. Kucherawy" <[e-mail]>]

On Tue, May 9, 2017 at 2:04 PM, Brandon Long <[e-mail]> wrote:

> In 5.1 defining the AMS, you say that it should cover DKIM-Signature and
> AuthRes headers.  In particular, AuthRes headers are expected to be removed
> by ADMDs, especially if the message transits the same ADMD multiple times.
> Also, the information in the AuthRes header is superseded by the ArcAuthRes
> header.  Including it means an arbitrary AMS breakage for something pretty
> minor, so I would recommend to not include it.
>

Section 5.1.2.1.1.... of the current draft says the same thing.  I just
copied it.


> You also talk about "responsibility".  I'm not sure that's how I would
> describe it.  An ARC hop is documenting that a message passed through it,
> and that it evaluated the authentication of the message.  The only
> responsibility of a hop is to correctly validate the SPF/DKIM/ARC
> information, there is no ownership implied over the message itself.
>

That's well-vetted language that's used to describe a valid DKIM signature
and its relationship (or more specifically, the relationship of the signer)
to the message content.  Indeed, if you affix an ARC seal to a message,
aren't you at least somewhat responsibility for its continued presence in
the ecosystem?  The language deliberately says "some responsibility"
because we don't want to make any specific judgements about culpability,
but the value of that metric is clearly not zero.


> With AMS, you can answer the question: which ADMD is the last ADMD to have
> modified the message.  I guess in that sense, the last modifier is
> "responsible" for the current state of the message... but that kind of
> means that the AMS of previous hops allows them to disown responsibility
> for the current state of the message...
>

Sure; in this sense ARC is different from DKIM in that you can make some
statements about various parts of the chain, rather than just the bits
whose signatures still validate.


> 5.2 - should we point out that there should be only one of these per hop?
> The openspf/dkim/dmarc implementations tend to add separate AuthRes headers
> for each evaluation, but ARC requires those to be a single instance.
>

Yes, there should be text about collapsing multiple values if they're
available when the seal is generated.  I think this was discussed elsewhere.


> 5.3.1 - none as defined as "arrives at an MTA from an MSA", perhaps my
> understanding of those terms is slightly odd, but I would think that an MSA
> usually uses an MTA to actually send the message, and it isn't that
> "sending" MTA that's the first hop, it should be the first "receiving"
> MTA.  I mean, that's usually the point at which the DKIM signature is
> applied, and the SPF would be "from" there, not based on the location of
> the MUA.
>

I'm using the definitions from RFC5598.  In many cases, a single component
serves as both the MTA and MSA.  But sure, clarifying text can't hurt.


> There are some missing pieces here, corresponding to the current draft
> sections 5.4 (alternate signing algorithms),
>

Sure, that could be added, though I think we should discuss why the time
ranges stated there are appropriate.  (This seems to me to be something
that might already have been addressed elsewhere in some other document
from the Security Area.)  If not (or even if so), this is perhaps work best
handled by DCRUP.


> 6.4.3 (arc email authentication method for AuthRes)
>

There should be text connecting this to the IANA Considerations, sure.


> 6.4.5 for dmarc xml.  I see that the arc is included in your IANA section,
> not sure if the call out outside of the definition is necessary or not.
>

What's the "call outside of the definition"?

-MSK