Subject: [dmarc-ietf] Clarifying question: AAR coverage by AMS

From: Seth Blank <[email-masked]>
Date: Thu, 25 May 2017 15:47:30 -0700

This might be a non-issue, but we're asking this question specifically
because we've run into an implementation issue within openarc that feels
weird and seems like a matter the WG may want to weigh in on.

Our expectation is that, for any given ARC Set n, AMS[n] would cover AAR[n].

Currently in openarc, AMS[n] covers all previous AAR[1..n-1] but *not*
AAR[n] because AAR[n] isn't created until substantially later in the flow.

Technically, this behavior is within spec as defined in
https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-03#section-5.1.2.1.1
:

   Participants may include any other header fields within the scope of
   the ARC-Message-Signature signature except that they MUST NOT include
   ARC-Seal headers fields.  In particular, including all DKIM-Signature
   header fields and all ARC-Authentication-Results header fields is
   RECOMMENDED.

Is it worth guaranteeing that, if signing AARs, AMS[n] must cover AAR[n]?

Or is this irrelevant because AS[n] is required to cover AMS[n] and AAR[n]?
But if so, why recommend the AAR be covered by the AMS at all in the first
place?

While the differences between these two assertions appear to be benign
(AAR[n] is always signed by AS[n], so whether or not it is in AMS[n]
shouldn't matter), the spec leaves room for confusion about the right thing
to do.

What was the original intention here and does this need clarification?

-- 

Bringing Trust to Email

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

---

From: Gene Shuman <[email-masked]>
Date: Tue, 30 May 2017 13:35:38 -0700

So I'm actively doing development on OpenARC right now, and this definitely
something that is being a source of some non-trivial awkwardness.

Can anybody recall why the aforementioned language of recommending
including the AAR's in the AMS is in there?  Afaik, it seems to make no
sense, and is causing some implementation specific awkwardness wrt both
OpenARC & the test suite.

So one would expect that for an ARC implementation, we would want a simple
configuration option that tells us which headers to sign.  I believe
OpenDKIM behaves in exactly this fashion.  And it needs to be able to
include duplicates, as that's a require feature of the rfc.  But this
recommendation to include AAR's in the list makes this awkward, as, as we
can't configure this in a similar fashion, as we dont know how many AAR's
are in messages a prior.

So either an implementation will either need some AAR inclusion
configuration option, independent of the other h= configuration list, or it
needs to make some internal decision of whether to be signing these headers
or not.  The first option is awkward & seems just kind of needlessly
complex.  And I'm also not a fan of implementations making this kind of
decision internally, as I think its important from a testing standpoint to
have the output headers be predictable.

So can anybody recall why this language is there?  It seems kind of
pointless in the best case, and slightly harmful in the worst.  Unless
somebody has a reason for it being there, I suggest we remove it.  Or why
not just actively forbid the inclusion of all ARC-Set header fields in the
AMS while we're at it?  That seems like a plausible idea.

=Gene

On Thu, May 25, 2017 at 3:47 PM, Seth Blank <[email-masked]> wrote:

> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-
> 03#section-5.1.2.1.1 :
>
> Or is this irrelevant because AS[n] is required to cover AMS[n] and
> AAR[n]? But if so, why recommend the AAR be covered by the AMS at all in
> the first place?
>
> +1-415-894-2724
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

---

From: Brandon Long <[email-masked]>
Date: Tue, 30 May 2017 15:00:40 -0700

On Tue, May 30, 2017 at 1:35 PM, Gene Shuman <[email-masked]> wrote:

> So I'm actively doing development on OpenARC right now, and this
> definitely something that is being a source of some non-trivial
> awkwardness.
>

I think this is broken.  Why would you ever configure "only sign two copies
of this header, but not three"?  I'd expect two lists, one of which headers
to sign, and one of which headers to add as empty to prevent extra copies
of the header to be added.  Ie, in dkimpy, that's the SHOULD and FROZEN
lists.

> AMS while we're at it?  That seems like a plausible idea.

The AMS was arrived at incrementally, as was the AAR (originally there was
just one AAR, not a full chain).  I guess it's not required, though I'm not
sure about the harmful part.

Brandon

---

From: Gene Shuman <[email-masked]>
Date: Tue, 30 May 2017 15:11:17 -0700

The two list approach to configuration actually seems sensible in general,
I'll discuss this with msk.

However, if the recommended AAR inclusion language accomplishes nothing,
shouldn't we remove it, regardless?

On Tue, May 30, 2017 at 3:00 PM, Brandon Long <[email-masked]> wrote:

>> So one would expect that for an ARC implementation, we would want a
>> simple configuration option that tells us which headers to sign.  I believe
> I think this is broken.  Why would you ever configure "only sign two
> copies of this header, but not three"?  I'd expect two lists, one of which
> headers to sign, and one of which headers to add as empty to prevent extra
> copies of the header to be added.  Ie, in dkimpy, that's the SHOULD and
> FROZEN lists.
>
>

---

From: Brandon Long <[email-masked]>
Date: Tue, 30 May 2017 16:17:21 -0700

So, history, the concepts of ARC come from the XOAR as implemented by
Google.

There, there is the XOAR header and it's covered by the
X-Google-DKIM-Signature header.  This translated to the AAR covered by
AMS.  ARC obviously has the second layer with the AS, which seems likely to
provide the same level of protection.

I don't really see the implementation challenge with requiring this, but
I'm open to removal if there is no utility to it.

I'm trying to think through scenarios to see if there's anything stronger
that this gives us, but I haven't seen any yet.

AMS covering AAR means that you could "trust" the AAR even if the chain
itself is compromised, but we've typically said "a broken chain should be
ignored", and I think that
statement should still hold.

There is the oddness that the AS and AMR don't have any requirements to be
the same.  With AAR not covered by AMS, you could replace the AAR/AS for a
hop, and sign the AS with a different key.  That means the AAR's trust
vector is just the AS and not both (AS/AMS).

Brandon

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

>> The AMS was arrived at incrementally, as was the AAR (originally there
>> was just one AAR, not a full chain).  I guess it's not required, though I'm
>> not sure about the harmful part.
>>
>> Brandon
>>
>
>

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 31 May 2017 09:38:08 +0800

> Our expectation is that, for any given ARC Set n, AMS[n] would cover

Yes, that is the intent. The set[n] is intended as a progressively built
comprehensive package:
1) evaluate DMARC for the message, if it fails and you are ARC-capable,
evaluate any preceding ARC[1..n-1] chain --> post your results into the
message as AR (expected to disappear if there are later hops) and AAR[n]
(subject to whatever protections you need within your ADMD/MTA chain until
the ARC-set is completed;
2) create and affix the AMS which covers the message, including AAR[n];
3) create and affix the AS which covers the ARC-set[n].

> AAR[n] because AAR[n] isn't created until substantially later in the flow.

That seems like an implementation flaw. AMS should be built in two phases,
both of which follow the creation of AAR[n]: a) blank "b=", b) calculate
the signature, c) append the signature to the end of the AMS header field
value.

I'll look at how to make this more clear in the I-D.

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 May 2017 13:35:16 -0700

> the signature, c) append the signature to the end of the AMS header field

What's the added value in covering AAR[n] twice, once with its b= and once
without?

-MSK

---

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

> What's the added value in covering AAR[n] twice, once with its b= and once
Sorry, that got out before my thought was fully formed.

What benefit is there to covering AAR with both the AMS and the AS?  It
seems to me the AMS is much cleaner (in the sense of ARC being a layer atop
DKIM) if it is purely a renamed DKIM signature with an instance number.

Put another way, the apparent intent here is to require that things be
generated in a specific order (AAR, then AMS, then AS) but it seems to me
there's no obvious benefit to imposing that constraint given that AS is
supposed to cover everything anyway.

-MSK

---

From: Brandon Long <[email-masked]>
Date: Wed, 31 May 2017 15:08:01 -0700

On Wed, May 31, 2017 at 1:42 PM, Murray S. Kucherawy <[email-masked]>
wrote:

>> What's the added value in covering AAR[n] twice, once with its b= and
>> once without?
>>
>>

Ignoring your DKIM bit, I can also see how this could be extended to think
about the oddness that having two signatures and whether the keys need to
match between AS/AMS.

One could imagine that the AMS was just a hash, and it would be a single
signature in the AS which covers it.  That's obviously more different than
DKIM, but reduces the size of the headers and makes a single point of
ownership.

Brandon

---

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

On Wed, May 31, 2017 at 3:08 PM, Brandon Long <[email-masked]> wrote:

>> On Wed, May 31, 2017 at 1:35 PM, Murray S. Kucherawy <[email-masked]
>> > wrote:
>>

Indeed, AS could sign (a) a locally-generated DKIM signature, with an
instance tag (since DKIM validators ignore tags they don't know), plus (b)
the current and all previous AAR/AS fields.

-MSK

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 1 Jun 2017 09:23:04 +0800

> supposed to cover everything anyway.

I need to go back to the notes as we were evolving the chain to see if we
discussed this particular piece and the logic for the sequencing.

Regarding: Thu, Jun 1, 2017 at 6:08 AM, Brandon Long <[email-masked]>
 wrote:

>
> . . .I can also see how this could be extended to think about the oddness
> that having two signatures and whether the keys need to match between
> AS/AMS.
>

There's another question that had been raised by Seth about whether d=
needs to match within an ARC set. The answer is yes, but we very explicitly
did not want to constrain ARC-writers to have to use the same keys (either
as their DKIM usage or within the ARC set) so the selectors may differ.
I'll be updating the language in the spec as I travel back to the US this
weekend and have a new draft early next week.

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 May 2017 21:10:43 -0700

On Wed, May 31, 2017 at 6:23 PM, Kurt Andersen (b) <[email-masked]> wrote:

> needs to match within an ARC set. The answer is yes, [...]
>

Why?

-MSK