Deprecate "dkim" authentication method for scenarios

[ikedas]

Expected Behavior

"dkim" authentication method for scenarios should be replaced with more effective feature.

Current Behavior

• Sympa's DKIM verification is very insufficient:
  • It succeeds if either of signature passes, regardless of the signer domain or identity (see Sympa uses the wrong domain for DKIM signature #1340). This means that a third party can add a signature to deceive the sender.
  • Since it is intended to verify the legitimacy of the address in the From: field, it can partly be replaced by DMARC verification.
  • On the other hand, if DMARC verification is to be performed, ARC verification should also be performed (in case that incoming message has been forwarded and has ARC seal(s)).
• Even though the scenario is shared between the mail interface and the web interface, the dkim method is available only with the formaer.
• It is complicated because there are many scenarios that differ only in whether the dkim method is valid or not.

Possible Solution

• Deprecate dkim method and make it an synonym of smtp method.
• Add a new global option parameter to reflect the results of DKIM/DMARC/ARC verification to the smtp method (equivalent to the dkim method) or not (same as the smtp method so far).
• Make DKIM verification more precise (consider signer domain or identity).

It would be possible for Sympa to take on DMARC/ARC verification, however the results of verification at MTA could be used as well as the current ARC support.

Context

[salaun-urennes1]

I'm not a DKIM/DMARC expert, therefor I suggest you ask David Verdin's point of view. He both knows very well Sympa and these protocols.

@dverdin could you give Soji your point of view on these propositions?

[dverdin]

OK, I'll give it a try.

Expected Behavior

"dkim" authentication method for scenarios should be replaced with more effective feature.

Current Behavior

* Sympa's DKIM verification is very insufficient:

No. Sympa's DKIM verification works exactly as it is expected in the RFC: it checks whether the DKIM signature is valid or not. That's the essence of the RFC. DKIM has never been intended to be a user authentication mechanism.
However, with a valid DKIM signature, you have the guarantee that the message was not altered, neither in the body nor in the signed headers, since the moment it was sent by the signing entity. That is something you don't have with plain SMTP.

  * It succeeds if either of signature passes, regardless of the signer domain or identity (see [Sympa uses the wrong domain for DKIM signature #1340](https://github.com/sympa-community/sympa/issues/1340)). This means that a third party can add a signature to deceive the sender.

Yes. However, that's a more important effort to perform than simply sending a fake message without signature. Most bots won't bother registering domains and sign messages.
But people wishing to perform more accurate phishings could do it. I think that's the reason why not much information is displayed about DKIM. End users could confuse a valid DKIM signature with a proof of identity from the sender, which would be counter-productve.
However, this behaviour in Sympa is also faithful to the RFC.

  * Since it is intended to verify the legitimacy of the address in the `From:` field, it can partly be replaced by DMARC verification.

I don't think it was ever intended for this. Having the "dkim" authentication level meant a little more confidence than smtp, because of the non message alteration described above. Also, when it was implemented 13 years ago, DKIM was less used, so most of the people having a DKIM DNS record had legal activity. At least "legal spam".
Practically speaking, most of the time, I handle dkim exactly the same way as smtp from an authorization point of view, because it gives no guarantee about the actual account used to send the message.
However, it is possible to moderate mails with the smtp authentication level and only request authentication for dkim-signed messages, on the principle that they have a slightly less chance to be forged, because it requires more effort. But, honestly, it is at best edgy.

DMARC could be used as a replacement of DKIM, but it does not give more information about the sender's identity. As DKIM, SPF and ARC, it is only a domain authentication mechanism, not a user authentication.
With DMARC, it is only harder to send a message on behalf of the sender. Most of the time, it requires taking control of a mail account, but anyone administering mail knows that it happens way too often.

Using DMARC supposes we have a front that creates the Authentication-Result headers based on SPF, DKM and DMARC. This front should do the rejection if the DMARC policy is "p=reject".
Afterwards, messages not rejected could enter the Sympa spools and be evaluated based on the Authentication-Results headers.
Here, it is difficult to have a clear "dmarc" authentication level. Because, if we follows the Sympa logic, only the mesages having "pass" in the "dmarc" Authentication-Result header could have this level and therefore a dedicated line in scenarios.
However, there is also the "quarantine" level, which could translate into moderation in the Sympa paradigm.
These could be treated as "smtp" but they are, in fact, worse, because thanks to DMARC we have a clue that they may be forged.
Consequently, we should also have a different behaviour for such messages, different from smtp. Maybe two authentication level: "dmarc-success" and "dmarc-failure".

  * On the other hand, if DMARC verification is to be performed, ARC verification should also be performed (in case that incoming message has been forwarded and has ARC seal(s)).

ARC verification adds a level of complexity because it supposes you have a reference of mail servers whose ARC headers you trust. That could be a new Sympa configuration file.
In addition, the pair "DMARC-failed / ARC-succeeded" implies a change in subsequent treatments because we must not add ARC headers, and let future receipient headers handle the DMARC failure based on their own reputation lists. But that's probably already done in Sympa, I did not check the ARC code yet.

* Even though the scenario is shared between the mail interface and the web interface, the `dkim` method is available only with the formaer.

Yes, but it is not a important. S/MIME is not available in a web context either.

* It is complicated because there are many scenarios that differ only in whether the `dkim` method is valid or not.

The upgrade process would certainly be a pain, yes.

Possible Solution

* [ ]  Deprecate `dkim` method and make it an synonym of `smtp` method.

* [ ]  Add a new global option parameter to reflect the results of DKIM/DMARC/ARC verification to the `smtp` method (equivalent to the `dkim` method) or not (same as the `smtp` method so far).

* [ ]  Make DKIM verification more precise (consider signer domain or identity).

The first point is probably a good idea. At least, it leaves the questions regarding DKIM to external systems better equiped to handles these RFC, such as Authentication-milter or Rspamd.

I'm not sure what the second one means, but if it means using DMARC and ARC as authentication levels ins scenario, then it will need revisiting the way the scenarios work to allow more nuances in authentication results assessment. The idea is: if the message passes DMARC authentication, we still have no guarantee it was sent by the sender in the From: field. But if it does not pass DMARC authentication, depending on the DMARC policy, the message should be either rejected (p=reject) and it should be rejected by the mail front, mooderated (p=quarantine) with a warning similar to those provided by the antispam scenario or treated as smtp (p=none).

The third point is wrong. You should not take the domain or identity into account while evaluating DKIM. That's DMARC'c job to do that. If you remove DKIM from scenarios, remove it completely.

It would be possible for Sympa to take on DMARC/ARC verification, however the results of verification at MTA could be used as well as the current ARC support.

Yes, as I wrote: Sympa is unlikely to be able to evaluate SPF, so it should user the Authentication-result headers of its mail front.
Which should probably set ARC headers itself.

[ikedas]

• Even though the scenario is shared between the mail interface and the web interface, the dkim method is available only with the formaer.

Yes, but it is not a important. S/MIME is not available in a web context either.

Please read the document.

ARC verification adds a level of complexity because it supposes you have a reference of mail servers whose ARC headers you trust. That could be a new Sympa configuration file.

Such configuration file (why the file instead of parameter, besides) seems not useful. What I wrote is that the message that has been modified in forwarding could validate the ARC chain instead of validating the DKIM signature.

Anyways I want to know: In the end, You think that the dkim authentication method is not helpful after all. Is it right?

[dverdin]

• Even though the scenario is shared between the mail interface and the web interface, the dkim method is available only with the formaer.

Yes, but it is not a important. S/MIME is not available in a web context either.

Please read the document.

I wrote it.
I forgot about it.

ARC verification adds a level of complexity because it supposes you have a reference of mail servers whose ARC headers you trust. That could be a new Sympa configuration file.

Such configuration file (why the file instead of parameter, besides) seems not useful. What I wrote is that the message that has been modified in forwarding could validate the ARC chain instead of validating the DKIM signature.

Anyways I want to know: In the end, You think that the dkim authentication method is not helpful after all. Is it right?

What is the point of writing an answer if you don't read them ? I said that removing the dkim authentication level was a good idea.
I tried to give pointer about going further, but I can see that I'm losing my time trying to give advice here.
Anyway, I did give a last try.

[ikedas]

• Even though the scenario is shared between the mail interface and the web interface, the dkim method is available only with the formaer.

Yes, but it is not a important. S/MIME is not available in a web context either.

Please read the document.

I wrote it. I forgot about it.

ARC verification adds a level of complexity because it supposes you have a reference of mail servers whose ARC headers you trust. That could be a new Sympa configuration file.

Such configuration file (why the file instead of parameter, besides) seems not useful. What I wrote is that the message that has been modified in forwarding could validate the ARC chain instead of validating the DKIM signature.
Anyways I want to know: In the end, You think that the dkim authentication method is not helpful after all. Is it right?

What is the point of writing an answer if you don't read them ? I said that removing the dkim authentication level was a good idea. I tried to give pointer about going further, but I can see that I'm losing my time trying to give advice here. Anyway, I did give a last try.

OK. I confirmed that this, dkim authentication method for scenarios, is one of the features that was only planned but not working properly.

In these years, I have been working on fixing many of those things to make them really usable or removing them to cleanup code. I am happy to be able to remove this. Thank you for answer.

[ikedas]

The interpretation of DKIM signature verification results is left to each ADMD, but on Sympa, it seems to have originally recognized this as a useless feature. So we'd be better no longer to associate DKIM verification results with user credentials. Therefore, I withdraw the second and third of the three solutions I proposed in my first post.

[ikedas]

I submitted update in documentation: sympa-community/sympa-community.github.io#95