Subject: [dmarc-ietf] ARC draft-10 Section 10 - Algorithm Rotation - can we address separately?

From: Seth Blank <[email-masked]>
Date: Thu, 28 Dec 2017 17:10:18 -0800

This got buried in two other threads (
https://mailarchive.ietf.org/arch/msg/dmarc/E9fOn8dIEiFqQJBz1GyFUimWVcM,
https://mailarchive.ietf.org/arch/msg/dmarc/Bv55cS12p41j3XhWzuu5RybvzTA) so
I'm just raising it to the top level.

Algorithm rotation is clearly more complex in ARC where you only have a
single chain than with DKIM where you can just affix multiple signatures.

That said, section 10 of the current draft (
https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-10)
feels clunky and itself says it needs more work.

Assuming we're proceeding as an Experiment, I propose we address rotation
in a separate draft.

---

From: "John Levine" <[email-masked]>
Date: 28 Dec 2017 22:57:41 -0500

>feels clunky and itself says it needs more work.

To put it mildly.

>Assuming we're proceeding as an Experiment, I propose we address rotation

I understand the motivation, but I think that if we do that, it makes
it a lot less likely that people will actually implement the
rotation stuff.

R's,
John

---

From: Seth Blank <[email-masked]>
Date: Thu, 28 Dec 2017 20:32:15 -0800

> it a lot less likely that people will actually implement the

Since there are only a handful of major implementations right now, all of
whom are participating in this group, I don't think there's a big risk of
this getting lost - unless we don't figure it out for many many months and
major implementors disengage. And as a maintainer and patron of several of
these implementations, this will be a priority as soon as it's baked, be
that in this doc or a separate one.

My strong bias (on my sleeve!) is to get the experiment rolling, and sort
other components that don't affect the experiment in separate documents.
The two that are top of mind are algorithm rotation and DMARC reporting,
but could also include A-R stamping if 7601bis needs more time.

Seth

---

From: Seth Blank <[email-masked]>
Date: Thu, 28 Dec 2017 20:34:40 -0800

And to be clear - I volunteer to write these documents and drive them to
completion.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 29 Dec 2017 09:37:56 -0800

> it a lot less likely that people will actually implement the

I still don't understand why we need to say more than DKIM did on this
topic.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 29 Dec 2017 13:36:23 -0500

> I still don't understand why we need to say more than DKIM did on this

DKIM doesn't have a chain of signatures.  With DKIM, a signature is either 
valid or not, and you can ignore the ones you don't understand.  ARC has a 
chain of ARC seals, and the current document says there's only one 
ARC-Seal header for each instance value so there can only be one chain 
using one algorithm per link.

One possibility would be what I suggested before, paired ARC-Seal headers 
that sign each other.  Another one that's simpler and probably workable is 
that all of the signatures in an AS chain have the same a= algorithm, and 
they ignore any AS or AMS with different signatures.

So if you understand one algorithm, you ignore any AS or AMS with other 
algorithms and hope you can find a chain with the one you understand If 
you understand both and there's a message with no prior AS, you add an i=1 
set with each algorithm.  If you understand both and there are existing 
chain(s), you add a new set for any chain that validates.

The intention is that there will always be a chain with rsa-sha256, and 
there might be a chain with ed25519-rsa256.  With multiple steps you might 
have, say, a three link rsa chain and a two link ed25519 chain if the 
third signer didn't do ed25519 so the software has to understand what that 
means.

I don't think this will be super complicated, but I do think it would be a 
mistake to try and publish now and then retrofit rather than adding it 
before we publish.

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

---

From: Seth Blank <[email-masked]>
Date: Fri, 29 Dec 2017 19:20:51 +0000

I’ll take a stab at proposing some language in a separate document.

On Fri, Dec 29, 2017 at 10:36 John R Levine <[email-masked]> wrote:

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

Bringing Trust to Email

Seth Blank | Director of Industry Initiatives
[email-masked]
+1-415-894-2724 <javascript:void(0);>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 29 Dec 2017 12:09:48 -0800

On 12/29/2017 10:36 AM, John R Levine wrote:
> DKIM doesn't have a chain of signatures.  With DKIM, a signature is 
> either valid or not, and you can ignore the ones you don't understand.  
> ARC has a chain of ARC seals, and the current document says there's only 
> one ARC-Seal header for each instance value so there can only be one 
> chain using one algorithm per link.
> 
> One possibility would be what I suggested before, paired ARC-Seal 
> headers that sign each other.  Another one that's simpler and probably 
> workable is that all of the signatures in an AS chain have the same a= 
> algorithm, and they ignore any AS or AMS with different signatures.
> 
> you understand both and there's a message with no prior AS, you add an 
> i=1 set with each algorithm.  If you understand both and there are 
> existing chain(s), you add a new set for any chain that validates.
> 
> there might be a chain with ed25519-rsa256.  With multiple steps you 
> might have, say, a three link rsa chain and a two link ed25519 chain if 
> the third signer didn't do ed25519 so the software has to understand 
> what that means.
> 
> I don't think this will be super complicated, but I do think it would be 
> a mistake to try and publish now and then retrofit rather than adding it 
> before we publish.

+1 to all of the above, I think.  (I don't usually leave a quote of an 
entire message, but the above seems pretty comprehensive to me.

Basically, ARC creates an 'infrastructure' by virtue of relying on 
multiple intermediaries, rather than just requiring participation in ARC 
by two endpoints.  And infrastructure are always much, much harder to 
convert to new details.

To ensure basic interoperability there needs to be the usual, basic, 
single convention (algorithm) that everyone supports AND USES. To permit 
upgrades, there needs to be the option of additional ARC chains using 
better algorithms.  My intuition is that requiring a given chain to use 
a single algorithm for all signers is the more workable approach.

I think a 'weakest link' argument is what defeats any claim that it 
would be better to allow individual signers to use better algorithms.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net