[dmarc-ietf] ARC Multi Proposal

[Scott Kitterman <[e-mail]>]

Originally, draft-ietf-dmarc-arc-protocol-00, ARC could use any signing 
algorithm supported by DKIM (which at the time were rsa-sha1 and rsa-sha256).

This was later reduced to rsa-sha256.

In the mean-time, DKIM dropped rsa-sha1 (RFC 8301) and ed25519-sha256 was 
added (RFC 8463).  In DKIM, the status of the algorithm requirements is:

    Signers MUST implement and SHOULD sign using rsa-sha256. Verifiers
    MUST implement rsa-sha256. (RFC 6376 as updated by RFC 8301)

    Signers SHOULD implement and verifiers MUST implement the
    Ed25519-SHA256 algorithm. (RFC 8463

DKIM also says:

3.3.4.  Other Algorithms

   Other algorithms MAY be defined in the future.  Verifiers MUST ignore
   any signatures using algorithms that they do not implement.

DKIM RFCs don't give any more advice than that.  It's left to operators to 
decide which algorithm to use (in the world where all RFCs are instantly 
implemented and deployed, it would be appropriate to sign only ed25519-sha256, 
but in reality we all know not to do that).

My personal experience with ed25519-sha256 signing indicates that DKIM 
implementers reliably considered the implications of 3.3.4 and it's safe to 
assume adding a new signature algorithm is unlikely to have backward 
compatibility implications.

ARC places some potential constraints on multi-algorithm support:

4.2.  ARC Set

   An "ARC Set" is a single collection of three ARC header fields (AAR,
   AMS, and AS).  ARC header fields of an ARC Set share the same
   "instance" value.

This requirement is the core of the problem that ARC multi needs to address.

I think we can define our way out of this relatively easily:

State that ARC uses all the algorithms used by DKIM (RFC 6376 as updated) - 
Section 3.3.

Add an expansion of the definition of an ARC set:

    If there are two AMS and AS signatures with the same instance (ARC i=)
    values that have different a= (algorithm), s= (selector), and b= (header
    hash) values, but are otherwise the same, then that is a single ARC set.

I believe that's it.  

It's backward compatible with existing implementations since all existing ARC 
implementations should be ignoring rsa-sha1 and ed25519-sha256 for ARC 
purposes.

When ARC implementations are updated to support ARC multi, they can use the 
expanded definition for identifying an ARC set with no changes needed to the 
underlying ARC processing.

It supports algorithm transition the same way DKIM does, no special rules 
needed.  It's up to the receiver (as always) to decide what input they trust 
and can use.

It avoids all the timing/flag day complexity that's in the current draft (and 
we know can never work).

Does it have to be any harder than that?

Scott K