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

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

On Thu, Jun 1, 2017 at 12:10 PM, Murray S. Kucherawy <[email-masked]>
wrote:

> On Wed, May 31, 2017 at 6:23 PM, Kurt Andersen (b) <[email-masked]>
> wrote:
>
>> There's another question that had been raised by Seth about whether d=
>> needs to match within an ARC set. The answer is yes, [...]
>>
>
> Why?
>
> -MSK
>

If an ARC-set is created by a single ADMD, I think it's reasonable for that
ADMD to identify itself in a singular manner, though I suppose we could
have recourse to our favorite "org domain" alignment instead of strict
matching if you think that's better. I think that strict d= matching is
simpler and less likely to be misused/broken.

--Kurt

---

From: Seth Blank <[email-masked]>
Date: Thu, 1 Jun 2017 11:18:11 -0700

I'm slightly confused.

I have a strong sense that the d= tag should be the same between the AS and
AMS within an ADMD. I can absolutely see why the s= might legitimately
vary. However, I can't seem the harm in the d= tag differing. If the
signatures validate, why should this matter?

Might this be simpler with language like "it is RECOMMENDED that the d=
value match between the AS and AMS, as any receiver might look at a
mismatch as suspicious."

i.e. Don't outright deny because maybe there's a legitimate reason to do
this that hasn't been discovered, and leave it up to receivers how to deal
with this?

Seth

On Thu, Jun 1, 2017 at 4:05 AM, Kurt Andersen (b) <[email-masked]> wrote:

> If an ARC-set is created by a single ADMD, I think it's reasonable for
> that ADMD to identify itself in a singular manner, though I suppose we
> could have recourse to our favorite "org domain" alignment instead of
> strict matching if you think that's better. I think that strict d= matching
> is simpler and less likely to be misused/broken.
>
> --Kurt
>

-- 

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: Thu, 1 Jun 2017 11:40:29 -0700

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

> On Wed, May 31, 2017 at 3:08 PM, Brandon Long <[email-masked]> wrote:
>
>> On Wed, May 31, 2017 at 1:42 PM, Murray S. Kucherawy <[email-masked]
>> > wrote:
>>
>>> On Wed, May 31, 2017 at 1:35 PM, Murray S. Kucherawy <
>>> [email-masked]> wrote:
>>>
>>>> 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.
>>>>
>>>
>> 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.
>>
>
> 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.
>

That's kind of the opposite direction of what I was thinking.

I'm saying, an AMS doesn't need a b= field, it could instead have an hh
field (header hash) or replace bh with a single hash field.

ARC-Seal: i=1; a=rsa-sha256; t=1496269322; cv=none;
        d=google.com; s=arc-20160816;
        b=dttRxs73FHsET5Zu1FVFwkpnS2bLmNcCXJKMBS5JPwBdfNIqBK7RH2P9K9SzXaBtg4

 rpXyIA+nigy2vHiKAP0hU8Cbh2lUtHXQbglvSiom91w+8UpDvvlGI8N4OP7Ju0iAvmfS

 XAxPGuXKCiyd48jZ+9QOqP1q39gd1mheUrkmFoVYzd9n5bkfwkazhkT05gk1bs16fnE4

 1fvOasGjlBvhDEzSv790k7i40NpwXuYRqhYgD3/ndxfT0l/uVJ0qp44krz0yRgyJebjo

 oNOeJT1dFL3l70BPnDtku5Wof77eD1Ql8rb5uGKnRgpYaaxh2Nt5PNQ0iLtFBWFTQo9c
         GL2A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:dkim-signature:arc-authentication-results;
        hash=3Yg5aVXobpP5fEP6VLnpuEPddr3SuybR7iVPPBvW59s=
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@gmail.com;
       spf=pass (google.com: domain of [email-masked] designates
2607:f8b0:400c:c05::22c as permitted sender) smtp.mailfrom=
[email-masked];
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com

This removes the confusion over separate s/d for AMS/AS, reduces the size
of the headers added by ARC, reduces the cost of signing/verifying (one
less encryption step, though that may not be the expensive part).

Ie, our current idea was the onion wrapping, AS wraps AMS which wraps AAR.
If we think more of them as a unit, then the signature in the AS is
sufficient for the whole unit.

Hm, though then, maybe it's not a Message-Signature but just a Message-Hash.

Brandon

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 2 Jun 2017 05:14:24 +0800

On Jun 1, 2017 11:48 PM, "Seth Blank" <[email-masked]> wrote:

I'm slightly confused.

That was our thought when writing the spec which is why the spec does not
speak to the issue (should be something in the usage doc IMO). I think Gene
raised the concern...Gene?

--Kurt

---

From: Gene Shuman <[email-masked]>
Date: Thu, 1 Jun 2017 14:43:19 -0700

I don't have particularly strong opinions here.  I can see no reason for
the d= to differ, but also no harm in allowing it do so.  So I think the
question of what to do here is slightly more philosophical. I think I
generally fall on the side of reducing user flexibility when nothing is
actively gained as opposed to granting user flexibility when there is no
harm.  But again, no real strong opinion on the matter.

On Thu, Jun 1, 2017 at 2:14 PM, Kurt Andersen (b) <[email-masked]> wrote:

> I have a strong sense that the d= tag should be the same between the AS
> and AMS within an ADMD. I can absolutely see why the s= might legitimately
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

---

From: Brandon Long <[email-masked]>
Date: Thu, 1 Jun 2017 15:32:19 -0700

> raised the concern...Gene?

I think we thought s might be different between arc and dkim, I don't think
we really considered it being different between AMS/AS.

That said, I don't think different selectors is that important.

I do think that having different domains for AMS/AS needlessly complicates
thinking about reputation/trust of the chain.  Do you trust based on AS or
on AMS, on either or only on pairs.

Without an example of a legitimate use case for them being different, I
think we should err on the side of requiring them to be the same (assuming
no one takes me up on my suggestion of removing it from the AMS entirely)

Brandon

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Jun 2017 22:28:01 -0700

> is simpler and less likely to be misused/broken.

I wasn't making any sort of claim about "better".  I'm just wondering if
there's a practical reason to say the two domains MUST or even SHOULD be
the same.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Jun 2017 22:30:37 -0700

> harm.  But again, no real strong opinion on the matter.

I'm taking the opposite approach: There might be some utility later to them
being different, so why proscribe it just because we don't see anything to
gain when the protocol is nascent?  I'd rather lock things down later, or
lock them down as a local policy matter, than do MUST NOT in the protocol
document absent a compelling reason.

-MSK

---

From: Seth Blank <[email-masked]>
Date: Fri, 2 Jun 2017 06:55:11 -0700

On Thu, Jun 1, 2017 at 10:30 PM, Murray S. Kucherawy <[email-masked]>
wrote:
>
> I'm taking the opposite approach: There might be some utility later to
> them being different, so why proscribe it just because we don't see
> anything to gain when the protocol is nascent?  I'd rather lock things down
> later, or lock them down as a local policy matter, than do MUST NOT in the
> protocol document absent a compelling reason.
>

I'm on the same page. Furthermore (and I say this mostly ignorant of IETF
precedent here), I think it's beneficial for the AS and AMS to remain as
close to normal DKIM-Signatures as possible, and additional constrains or
variance in acceptable tags/values or semantical constraints across them be
kept to a bare minimum. I think everything else really belongs as local
policy for a receiver, unless there is specific and clear benefit to the
protocol to impose the restriction.

I don't think requiring d= to match between AS and AMS clears this bar for
the protocol, but it absolutely makes sense for a receiver to factor into
delivery decisions. And then, as MSK just said, if a good reason for doing
this arises later, it's possible. And if a malicious use arises, then
receivers are still in their right to shut those chains down and might
already be doing so by default.

Seth

-- 

Bringing Trust to Email