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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 4 May 2017 00:56:00 -0700

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

---

From: Seth Blank <[email-masked]>
Date: Thu, 4 May 2017 08:00:19 -0700

Murray,

This is very helpful, thank you. I find section 7 easier to follow than
Kurt's pseudo code in
https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-03#section-5.1.1.5.1

Quick bug (I think): In 7.5, you say "If no seals pass validation" but I
think you mean "If all seals pass validation".

Additionally there is a discrepancy between your section 7 item 5 and
Kurt's pseudo code. As I'm reading it, your logic allows a chain with a
cv=pass at i=1 to be valid, and Kurt's does not. I believe Kurt's is
correct, especially based on your definition of the cv=none value in 5.3.1
of your draft.

Thanks! Sure I'll have more feedback soon,

Seth

On Thu, May 4, 2017 at 12:56 AM, Murray S. Kucherawy <[email-masked]>
wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

-- 

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols
[email-masked]
+1-415-894-2724 <415-894-2724>

---

From: Brandon Long <[email-masked]>
Date: Tue, 9 May 2017 14:04:54 -0700

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

---

From: Gene Shuman <[email-masked]>
Date: Tue, 9 May 2017 15:56:01 -0700

I've taken a look at the proposed draft and have a few notes as well.

4.  The currently specified limits on i= are not included MUST >10, SHOULD
> 50, etc

5.1 - In the current draft, it's mandated that AMS must use relaxed header
canonicalization, but that's missing from the proposed draft

5.2 - I'm a bit confused by the comment noting the importance of i=2.  What
is it that you're intending there?

5.3.1 - typo:  one of three possible values: -> one of *four* possible
values

7.2 - It may be worth elaborating more on the possible ways in which
cv=invalid can arise, if not here, maybe somewhere else

7.4 - In general I prefer this to the psuedo code in the current draft, but
I think it could still use a bit of work.  In particular, sections C-H are
exactly describing how to validate a DKIM signature and seems somewhat
unnecessary. Is there any particular reason you decided to include this, as
opposed to just relying on the DKIM spec for this?

7.5 - typo: no -> all

In general though, I agree with Brandon, the proposed draft definitely
makes some things clearer, which I think is a step in the right direction.

=Gene

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

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

---

From: Seth Blank <[email-masked]>
Date: Tue, 9 May 2017 17:39:45 -0700

I've got two follow ups from Gene's notes on the proposed draft:

1. I am also confused by section 5.2, specifically the penultimate sentence
in the section. I think - but am not certain - that I understand what is
meant. I've suggested new language below to clarify.

Original:

"Of particular importance is the recording of the "i=2" instance of this
field, which is the first available opportunity in the handling chain of
the message to evaluate its apparent validity since departing its
originating ADMD."

Suggested:

"Of particular importance is the first AAR header after an ARC signed
message leaves its originating ADMD, which is generally but not always the
"i=1" instance of this field. This instance contains the authentication
information of first receipt which the ARC chain is establishing custody of
to a final receiver."

2. Also, in section 9.5, an IANA Consideration for "temperror" is defined
but I think this was supposed to be for "invalid".

Seth

On Tue, May 9, 2017 at 3:56 PM, Gene Shuman <[email-masked]> wrote:

> 5.2 - I'm a bit confused by the comment noting the importance of i=2.
> What is it that you're intending there?
>
> 7.4 - In general I prefer this to the psuedo code in the current draft,
> but I think it could still use a bit of work.  In particular, sections C-H
> are exactly describing how to validate a DKIM signature and seems somewhat
>> 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
>> 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.
>>
>> On Thu, May 4, 2017 at 12:56 AM, Murray S. Kucherawy <[email-masked]
>> > wrote:
>>
>>> Colleagues,
>>>
>>> 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.
>>>

-- 

Bringing Trust to Email

---

From: Brandon Long <[email-masked]>
Date: Wed, 10 May 2017 00:34:15 -0700

> canonicalization, but that's missing from the proposed draft

I think that 5.1.2 in the current draft is wrong, it's overridden by 5.1.2.1.2.
We started out only allowing relaxed, but then added back support for c= in
a later draft.

Brandon

---

From: Seth Blank <[email-masked]>
Date: Wed, 24 May 2017 15:55:48 -0700

Looping back about this.

Currently openarc only supports relaxed canonicalization for the ARC
Message Signature.

On closer inspection, https://tools.ietf.org/html/
draft-ietf-dmarc-arc-protocol-03#section-5.1.2 and https://tools.ietf.org/
html/draft-ietf-dmarc-arc-protocol-03#section-5.1.2.1.2 do *not* appear to
be in direct contradiction of each other.

5.1.2 states that AMS header canonicalization must be relaxed, and
5.1.2.1.2 says that AMS body canonicalization must respect the c= value.

Is this what was intended (AMS headers=relaxed, body=[c value]), and should
be included in the proposed draft? Or should the entire AMS (headers and
body) respect the c value and both specs be updated?

Seth

On Wed, May 10, 2017 at 12:34 AM, Brandon Long <[email-masked]> wrote:

>> 4.  The currently specified limits on i= are not included MUST >10,
>> SHOULD > 50, etc
>>
>> 5.1 - In the current draft, it's mandated that AMS must use relaxed
>> header canonicalization, but that's missing from the proposed draft
>>
>
>>> 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
>>> 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 <
>>> [email-masked]> wrote:
>>>
>>>> Colleagues,
>>>>
>>>> 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.
>>>>

-- 

Bringing Trust to Email

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 May 2017 15:24:44 -0700

On Wed, May 24, 2017 at 3:55 PM, Seth Blank <[email-masked]> wrote:

> On closer inspection, https://tools.ietf.org/html/dr
> aft-ietf-dmarc-arc-protocol-03#section-5.1.2 and
> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protoco
> l-03#section-5.1.2.1.2 do *not* appear to be in direct contradiction of
> each other.
>
> Is this what was intended (AMS headers=relaxed, body=[c value]), and
> should be included in the proposed draft? Or should the entire AMS (headers
> and body) respect the c value and both specs be updated?
>

For that matter, why is "c=" required, and why are we constrained to
"relaxed" for headers?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 May 2017 15:40:34 -0700

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

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

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

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

> applied, and the SPF would be "from" there, not based on the location of

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.

> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 May 2017 15:46:07 -0700

> 4.  The currently specified limits on i= are not included MUST >10, SHOULD

50 seems oddly high.  I think sendmail out-of-the-box limits you to 20
Received fields, for example.

> canonicalization, but that's missing from the proposed draft

Deliberately.  What's the purpose of that limit?

> What is it that you're intending there?

Ask Seth.  :-)

> 5.3.1 - typo:  one of three possible values: -> one of *four* possible

Fixed in source.

> cv=invalid can arise, if not here, maybe somewhere else

Sure.

> opposed to just relying on the DKIM spec for this?

Mainly because of the fact that there are considerations around the "cv"
before and after that set of steps.  I'm not partial to a list of steps
part of which live in some other document.

> 7.5 - typo: no -> all

Fixed in source.

-MSK