Wei Chuang wrote in <CAAFsWK0MWsD0RtkfoiOKSKpY-hfcpNDdR-HmDqt=wur5y6=e...@mail.gmail.com>: |Just following up here. At the DKIM interim -05, PQC was discussed; the |direction is to use a composite aka hybrid: ML-DSA-44 / Ed25519 to support |PQC. This would apply only to DKIM2, skipping DKIM1. The belief is that |the update could be done as small text additions to existing drafts rather |than requiring a new internet-draft. Assuming that, we'll need new text |for the draft-ietf-dkim-dkim2-spec and draft-ietf-dkim-dkim2-dns.
I have only glanced over all these messages in the past, but double-base64 encoding to satisfy a data exchange format (that is per se misdefined regarding its string format) that is not needed for a DKIM task seems just as monstrous as other things i have pointed out often, and now ... you are going to even kill easy DNS over UDP for your misdesigned thing? No. That MSDSA44 thing was a good thing to have early, so that protocols like SSH can act as soon as possible. I have for example switched all my keys to that, already. (In how far attackers could decrypt saved-away SSH sessions at a later time otherwise, that is to be answered by SSH experts. (Noone will spend the effort my SSH sessions, anyhow.)) In so far, MLDSA44 is a good thing. Other than that it is an early algorithm, next years NIST consideration will include algorithms which were thought with more time spend on thoughts on post-quantum, and it includes several with properties that fit much better tasks of DTLS and DKIM. So. I can assure you. DKIM/ACDC that is post-quantum only will keep the 40+ years DNS over UDP alive, even with DNSSEC records included. Even over DTLS it should work. And with EDNS even post-quantum DTLS should work out, today already with MLKEM and the massive standard wave the IETF threw on that early MLKEM design (for which the same is true as was said for MLDSA, right), with all those new DNS entries and whatever else is now implemented in code. Likely, algorithms of the NIST consideration of 2027 will dramatically reduce also those TLS handshakes again, too. (Still, likely EDNS is needed for DKIM/ACDC DNS over UDP with DNSSEC and DTLS.) In short: instead of waiting a few more months to get really proper algorithms, this WG blows DNS/UDP for email processing. For signatures that have a lifetime of a week (10 days for DKIM/ACDC), and have no value thereafter. That is irresponsible. Yes, this WG is ingenous -- if i would go Halloween i would consider a DKIM2 costume! That is the most frightening thinkable thing really. Halloween seems a good release date for this DKIM2!!! But what was said on algorithms by Levine is true. For DKIM/ACDC, dependent on the outcome of the NIST 2027 (just a few months..), and dependent on what real cryptographers state (as opposed to AI sayings), DKIM/ACDC *could* really turn the hybrid into a single algorithm. That is to say, that after the post-quantum flag date (0x71717171 hexadecimal, ISO 8601 2030-04-24T11:20:17Z) its eddapq-sha3-256 *could* loose its ED25519 part, because for example FAEST seems to satisfy "normal" cryptography out of the box already. That seems a sensible approach, it will be mentioned in the upcoming, and hopefully very very last, draft of DKIM/ACDC. May it then rest in peace beyond a world where evil rules. --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 -- [email protected] To unsubscribe send an email to [email protected]
