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

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.

Our implementation explicitly blacklists that header.

I know some mailing lists also strip the DKIM-Signature header, but since
they are likely to break the AMS anyways, that's less important.  I'm not
sure what the benefit is to including it, but it seems harmless.  In
particular, if the DKIM-Signature still passes, then the ARC isn't adding
that much, and removing the DKIM-Signature header doesn't mean all that
much either since it's validity was already assessed and that assessment
included in the AAR.  We don't blacklist the DKIM-Signature method in our
implementation, but I don't understand the advisement.

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.

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

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.

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.

There are some missing pieces here, corresponding to the current draft
sections 5.4 (alternate signing algorithms), 6.4.3 (arc email
authentication method for AuthRes), 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.

Overall, I think your draft makes some things clearer, and some things in
the original are clearer.  It's worth looking into either combining or
choosing.

Brandon

On Thu, May 4, 2017 at 12:56 AM, Murray S. Kucherawy <superuser@gmail.com>
wrote:

> Colleagues,
>
> As I progress (slowly, alas) toward completing my sample implementation of
> OpenARC, I've found myself taking a lot of notes about the current draft.
> This has helped me make progress; in some cases it became things I posted
> to the list, and in others it was just to help or confirm my understanding
> of the protocol.
>
> I have developed this enough to become a fairly comprehensive alternative
> text to the current draft.  I find the layout of this version to flow
> better for my own purposes, and in a few places I've tried to clarify some
> of the material by rewriting chunks of it.  None of this is meant to assert
> that the current draft is deficient; I've just found it to be a helpful
> exercise for me.
>
> I offer it here to the WG as a contribution; the WG of course is free to
> use some, all, or none of it as it wishes.
>
> http://blackops.org/~msk/draft-kucherawy-dmarc-arc-base.txt
>
> If it would be more helpful to post this as an I-D, please let me know.
>
> -MSK
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
>