On Sun 20/Jul/2025 18:55:58 +0200 Wei Chuang wrote:
On Sun, Jul 20, 2025 at 2:56 AM Alessandro Vesely <[email protected]> wrote:
On Sat 19/Jul/2025 21:41:27 +0200 Wei Chuang wrote:
My sense is that over the lifetime of "DKIM2" there will be more algorithm
introductions than circumstances where there is an algorithm breakage, and the
algorithm introductions need to be supported and encouraged for algorithm
diversity. I suspect a MUST would discourage that.
Your wording is a bit obscure to me. Did you say a MUST would discourage the
trend to support and encourage algorithm diversity? While some would have
hoped otherwise, that seems to be what happened with ed25519, as RFC 8463
states:
Signers SHOULD implement and verifiers MUST implement the
Ed25519-SHA256 algorithm.
My worry is that if receivers lack some latitude for applying local policy
during new algorithm introductions it will introduce a denial of service
scenario. A strict interpretation of the above MUST, is that even if the
new signers or new verifiers are immature, and introduce false verification
failures, is to use those results. Senders knowing this will be
discouraged from introducing new algorithms due to the deliverability
impact. I interpret Barry's proposal as providing some latitude for
introducing those algorithms.
That's right. Ed25519 signatures are often reported as an error rather than
ignored, which is a reason to stop them. Instead, the RFC could have stated
that signers MUST implement and verifiers MUST report the lack of the new
signature as an error. Senders jump through hoops to avoid errors in aggregate
reports.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
