On Tue, Jul 28, 2026 at 8:38 AM John Levine <[email protected]> wrote:
> It appears that Wei Chuang <[email protected]> said: > ... > >I also looked around DNSOPS for PQC advice. I found that they seem to be > >actively working > ><https://mailarchive.ietf.org/arch/msg/dnsop/Yr6A91U5gbjZ_L6NkMj8mbgTeQE/ > > > >on rules for handling greylisting algorithms on short notice via > >draft-huque-dnsop-multi-alg-rules > ><https://datatracker.ietf.org/doc/draft-huque-dnsop-multi-alg-rules/>. > We > >likely need a similar discussion for DKIM2 on how to gracefully handle > >greylisting of the classical RSA/Ed25519 signature. > > As I said in DNSOP, I think this is a bad idea becauase I don't think that > a typical DNS operator (or mail operator) knows enough about cryptography > to use such a feature sensibly. > > If you think a signing algorithm is broken, just stop signing with it. > I think that DKIM signatures are likely to be pretty far down the list > of things attacked with PQ computers since they're short lived and the > stuff they sign is usually low value. If I want to phish people, there > are a lot cheaper ways than using a quantum computer to make a fake > DKIM signature. > > Re the "AND" thing, if we really think that's important, we can add > a double signing algorithm where the keys and signatures are the > two individual ones concatenated. No need to add more complication > to the spec. > Also note that Stephen > >suggested signing and validating ML-DSA-44/65 with RSA/Ed25519 a "AND". > >Second, DNSSEC was able to more widely deploy > ><https://www.icann.org/en/system/files/files/octo-033-04apr22-en.pdf> an > >alternative to RSA i.e. ECDSA than DKIM which is predominantly RSA. > > Key rotation in DKIM1 doesn't work in practice, mostly because you have > to have separate selectors for different algorithms which means double > signing, which risks losing mail in badly designed receivers that > penalize signatures they can't verify. I think we fixed this in DKIM2. > > Also, the DNS crowd puts a lot of emphasis on keeping responses small. > While ed25519 is smaller than RSA, it's not enough smaller that it > would make any different in mail handling. > > Just wanted to point out that the current -04 DKIM2 spec <https://datatracker.ietf.org/doc/html/draft-ietf-dkim-dkim2-spec-04#name-perform-the-signature-verif> has wiggle room on how to interpret multiple signatures. It only mandates PERMAIL if all signatures fail in a DKIM2 signature header field. My read is that it is up to local policy whether to "AND" multiple signatures, or to "OR" them. This helps with the the ramp up of a new algorithm because it does not hinder deliverability as has happened with DKIM1, as you state. It also gives the receiver the ability to switch from classical to PQC, or require both when available. However depending on local-policy interpretation by the receiver, may cause confusion to senders when that interpretation changes. -Wei
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
