[Mailman-Developers] Basic workflow of the ARC implementation

[Aditya Divekar]

Hi Steve!

Now going back to the implementation, the message needs to be signed after
its headers have been cooked, since they are included in some of the
signatures below.
So after the message headers have been cooked, and before the message has
been enqueued by the switchboards onto the various queues, we shall
catch the email, and perform the ARC operations on it as given below. After
this we can reinject the mail into the queues. This can be done by
modifying the process that handles the queuing of the mails.(This can be
done when the integration process into Mailman starts later on)

For now, I will assume that only the message is available to us in its
complete form after the list has cooked its headers.

We need to generate a private and a public key for the signing purposes.
For testing purposes, and while working on the code, I can probably
generate the keys locally using the openssl tool.

As a rough sketch of implementation,

1. ARC Seal

The tags -

NOTE - Now, here we needed to check the given message for any pre-existing
signatures in most of the fields. For this I think a separate module can be
created which can extract the previous ARC headers if they exist from the
message. The code for this can be again used from the dkimpy package.

i: The value for this tag can be determined by performing a check on the
original signature
and seeing if there were previous ARC headers. If yes, we increment the
value of the previous "i" by 1,
and if no, make it 1.
a: The value for this is fixed.

t,s,d: These can be obtained by using pre-existing dkimpy package.

b: Now we can compute the header hash using the dkimpy package again by
using the headers given here
<https://tools.ietf.org/html/draft-andersen-arc-02#section-5.1.1.3>. Here,
we call the dkimpy package and get the signature for the above headers and
then affix it to the "b="header.

cv: Use the same check as "i", if there is already an ARC i.e. i>1, then we
make it as "V", else "N".

The ARC Seal gets computed here.

NOTE-For giving the "s" and "d" (selector and domain tag values), we will
need to produce records for these where the key can be stored so that it is
available for query by the verifiers (I still have to look up this
mechanism).

2. ARC Message Signature

The tags -

i: The value for this tag is determined similar to the "i" tag for the ARC
Seal.

a,t,s,d: These can again be obtained from the dkimpy package.

bh: The body hash. This can be obtained from the package. Here, we set the
canonicalization to 'relaxed' and get the body hash.

h: The "h=" header list is signed with the implicit list (as given in the
draft) and any explicit list that we want in addition.
Now, for mailing lists, the recommended headers are -
List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:Reply-To:
and any other fields added by the list like the Precedence, XTopics or
else.
We will also sign the DKIM signature of the previous mail here if
available(suggested by the draft).
For this signing, we can use a modified version where the
FROZEN_HEADERS(headers that are signed by default) will specify the
implicit headers                                     according to ARC
specs(Another option could be to get all the implicit+explicit headers
signed by the package, extract the h header, and modify it to include only
the explicit headers.)
b: The signature, calculated from the package. The h tag is used as
described above.


3. ARC Authentication Results.
The "i" tag simply takes on the value same as the above "i" tags.
Now from our previous conversation, as you suggested, the authenticity of
the previous MTA who sent us the mail is not sure to be trusted. So in the
case where we don't trust the previous MTA, we will have to perform our own
DMARC, SPF, DKIM testing of the recieved mail. If previous ARC chain exists
i.e. cv=V, then we perform the ARC test too.
Now for performing the tests -
In one of the earlier mails, we discussed the use of the "authres" package
for generating the authentication results header. The package conforms to
the RFC7001 format, and now the format used is RFC7601. But according to
the changes that I verified, we can use the package without any changes.
(The changes were mostly related to extra specifications that are optional.
Can be skipped for our purposes)
So the "authres" package can be called here for generating the AAR.

If we need to perform the ARC test, then the module for that will have to
be implemented manually. Though most of the code from the package for DKIM
verification can be used.
This is also the point where we detect if the mail is spam or not. If the
arc test fails, then there is something fishy here. DKIM, DMARC, SPF may
fail, but the failure of this test means the mail is not authentic. At this
point the mail should probably be discarded (or any other measures that
need to be taken).

Now coming to the testing part. There can be a number of tests like
verifying the generated ARC signature, changing the body of the message,
failing when the implicitly signed AMS headers are changed and other such
tests.

Is this the workflow you were expecting to see, or should I write a more
explanatory draft ?
I would like to know your review of this, so that I can figure out if I am
going wrong anywhere. :)

(Also wherever I have mentioned the use of dkimpy, a lot of custom
implementation is needed to suit our requirements. )

Thanks!

Aditya