Subject: Re: [dmarc-ietf] ARC Multi Proposal

From: "John Levine" <[email-masked]>
Date: 2 Nov 2018 07:56:21 +0800

In article <9957335.dUWMaE32Bo@kitterma-e6430> you write:
>Does it have to be any harder than that?

I hope not but it's still not backward compatible so it's not really any better.

With the current spec, if you have two AMS or AS with the same i=
that's invalid, so if you start putting both rsa and ed25519 seals,
old verifiers will probably fail.  It'd be interesting to mock up
dual seals, send them to Gmail et al, and see what they think.

I suppose we could invent new headers EAMS and EAS and EAAR for the second
and later version of seals, but ugh.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 02 Nov 2018 00:35:08 -0400

> and later version of seals, but ugh.

I agree having data would help a lot here.  We're starting from different 
assumptions and there's no way to know which is better without data.

I am assuming that ARC implementations have the DKIM like property of ignoring 
signatures signed using algorithms they don't implement.  I don't know if 
that's a correct assumption or not.

Scott K

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 2 Nov 2018 17:26:51 +0900

On Fri, Nov 2, 2018 at 8:56 AM John Levine <[email-masked]> wrote:

> that's invalid,

No, it is not invalid. We did try to downplay the details a bit in the
spec, but if you use a different signing algorithm, you can have as many
ARC sets with the same instance as you have legal algorithms.

--Kurt

---

From: "John R Levine" <[email-masked]>
Date: 2 Nov 2018 15:51:30 +0700

On Fri, 2 Nov 2018, Kurt Andersen (b) wrote:
> No, it is not invalid.

I mean ARC as it's implemented now, not in our multi-signing draft.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 2 Nov 2018 17:56:06 +0900

> I mean ARC as it's implemented now, not in our multi-signing draft.

It seems like a poor implementation choice to be enforcing something which
is not part of the spec :-), especially when there are parenthetical
comments and references to things like ARC-MULTI to warn you against
leaping to foot-shooting enforcement choices.

--Kurt

---

From: "John R Levine" <[email-masked]>
Date: 2 Nov 2018 16:07:03 +0700

> leaping to foot-shooting enforcement choices.

Here's what the spec says:

    3.  Validate the structure of the Authenticated Received Chain.  A
        valid ARC has the following conditions:

        1.  Each ARC Set MUST contain exactly one each of the three ARC
            header fields (AAR, AMS, and AS).

I don't see where it says "except you can ignore the ones that don't 
validate particularly if they have funky algorithms."

The perl ARC module checks for dup headers and I don't think that's 
unusual.

Regards,

---

From: "John R Levine" <[email-masked]>
Date: 2 Nov 2018 16:08:58 +0700

> leaping to foot-shooting enforcement choices.

I see it also says:

    Valid ARC Sets MUST have exactly one instance of each ARC header
    field (AAR, AMS, and AS) for a given instance value and signing
    algorithm.

I'm reasonably sure that doesn't match a lot of running code.  I'm 
particularly thinking of gmail here.

Regards,

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 2 Nov 2018 05:13:21 -0400

> particularly thinking of gmail here.

That should be easy to test but not with a tiny keyboard as I board my
flight from ICN --> BKK.

--Kurt

---

From: Brandon Long <[email-masked]>
Date: Mon, 5 Nov 2018 13:06:13 -0800

> That should be easy to test but not with a tiny keyboard as I board my

If it does work, I'd be a surprised.  Most likely, it'll fail validation
prior to full parsing (we extract the i= first, and only fully parse all
the k=v pairs later).

Also, does that mean you have to use the same algorithm in both the AMS and
AS for a given instance?  And how does that correspond to an AAR which
doesn't have an algorithm... and how does that work with the AS signing
previous headers, does it only sign the ones with matching algorithm?

I'd be a bit surprised if all of those caveats are correctly matched in the
original arc spec.

Brandon

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 05 Nov 2018 16:23:40 -0500

On Monday, November 05, 2018 01:06:13 PM Brandon Long wrote:
> >> > It seems like a poor implementation choice to be enforcing something
> >> 
> >> which
> >> 

OK.  Thanks for the implementation feedback.

Do you have any suggestions for a change that would make an AMS/AS be silently 
ignored?

My thought had been one AMS/AS pair per algorithm (treated effectively as one 
AMS/AS) and a single AAR.  I guess it won't be that easy.

Scott K

---

From: "John R Levine" <[email-masked]>
Date: 6 Nov 2018 10:08:46 +0700

> previous headers, does it only sign the ones with matching algorithm?

That's in my draft.  Each chain of seals uses a single algorithm, so the 
AS and AMS algos all have to match.  There's no signature in the AAR so 
it's shared between multiple seals in the same instance.  You're only 
allowed to seal the longest chain(s) so if the longest chain uses an 
algorithm you don't understand, it fails.

> I'd be a bit surprised if all of those caveats are correctly matched in the

No kidding.

Regards,