Viktor Dukhovni wrote in <dc85f374-b15c-442c-9f5e-15b4eea30...@dukhovni.org>: |> On 16 May 2024, at 10:02 AM, Hector Santos <hsantos=40isdg.net@dmarc.i\ |> etf.org> wrote: |> I don’t wish to oversimplify here, but I wonder if the confusion \ |> is with the idea that in order to support RFC8463, a complaint implement\ |> ation would have to sign two DKIM signatures for backward compatibility. \ |> One DKIM signature using SHA256 and a second signature using Ed25519. | |No, you're conflating completely different constructs, because SHA256 \ |is NOT a signature, it is a message digest.
And i think he mentions an interesting point, given that people on the dkim list said that they use the Ed keys since 2019, and "without problems", which is i think the correct citation. That is five years and still you need to DKIM-double-sign your emails, because major email player with which you have to be compatible to simply do not follow this spec. Truy, i have heard that "just use the rsa-sha256 and be good" quite some times in the past months where i was so deeply involved in this topic. It surely results in smaller messages and less resource consumption, .. especially if there is no light on the horizon that the situation will change for a better. ... [resorting for effect] |Nevertheless, the specification is clear enough, and a slightly different \ |code path for the new signature scheme is fine. No. That is not necessarily a necessary evil. We have that problem with some other email standards, where each and every one invents its own [un]"structured header" format, just slightly different, but which needs to be addresses specifically. You can see how serious the people treat the standards if you look into the code, you see the blurred corners and the generalized parsers. This can be said about the plain DKIM RFC 6376, too, as it uses VCHAR; i presumed it did so for simplicity as that means "no comments", no quoted-pairs, no quoted-strings etc, and so it is. On the other hand noone would be hurt if the entire IETF email standards would focus on RFC 5322 and RFC 2045 with their near 50 years of defined content, and clear syntax elements like atext and the mentioned, and rules like key=value or key="value" etc, instead of inventing things which look easy but are entirely different like key(FWS)=(FWS)value1(FWS that counts)value2, and similar monsters. (Again: artificially complicated.) I do not know why this can be seen all over the place, but it is there. Sure, yes, you can, .. but i at least would not. (In the meantime if have changed the post-release code of the little thing i have written so it is generalized via "extern_md" and "sign_md" booleans, but i would be eager to drop the former again.) ... |Nothing of the sort, the computational costs are trivial, there is \ Well if you have to place two further ARC signatures then maybe. The following Ed25519 computations are less than trivial for sure. On the OpenPGP list i think it was where they had a deeper look at "whether it should be SHA-256 or SHA-512" (for whatever purpose), and it depends a lot on crypto extensions, and 32-bit or 64-bit CPUs etc. And i think the IETF email group should possibly step down from usurping the small CPUs of the little servers of poor students, there is also the TLS and HTTP community which longs for taking its toll. |some additional code required for Ed25519 support, because |instead of using a single Digest+Sign primitive in, e.g., OpenSSL, \ |the caller needs to first compute a message digest, and |then pass it to Ed25519 for signing. This is OK. One might argue \ |that this should have been either pure Ed25519 over the raw |data (contrary to the text of the base DKIM RFC, but aligned with how \ |it ultimately handles RSA), or, else Ed25519ph which is |explicitly design for hashed input (but APIs for which are not yet \ |mature in OpenSSL). Of course i give in because "ultimately" the RSA key signs the digest of the headers, just like the digest of the headers is passed into the Ed25519 algorithm. But again i will point to the possible future in fall this year, when i would try to write a draft that changes this, because i see no reason why we must be totally fixated on it, *if* the sig-alg contains (even extensive) digesting itself, we could very well "simply pass the headers", like the developer of the four letter MTA wrote, and the result will not be less secure or or lesser quality, but possibly even better. --End of <dc85f374-b15c-442c-9f5e-15b4eea30...@dukhovni.org> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
