[Ietf-dkim] Re: PQC Threat Model statement

[Wei Chuang <[e-mail]>]

On Thu, Oct 15, 2026 at 6:09 AM Hannah Stern <hannah.stern=
[e-mail]> wrote:

> Hi!
> On 7/28/26 17:38, John Levine wrote:
>
> It appears that Wei Chuang  <[e-mail]> <[e-mail]> 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/> <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/> <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.
>
> I've become convinced that John's argument here offers the right
perspective on finding a suitable PQC algorithm.  In
draft-ietf-dkim-dkim2-dns-01
<https://datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-dns/01/> we
introduced the composite PQC  algorithm mldsa44-ed25519-sha512; however,
I'm worried that the downsides outweigh the security improvements it
brings.  I agree that we shouldn't underestimate the difficulties of
introducing a new algorithm, as we saw with the friction of getting DKIM
operators to adopt Ed25519.  I've recently heard one reason was library
compatibility issues.  See draft-ietf-dkim-dkim2-dns-01
<https://datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-dns/01/> appendix A
for a description of the RSA key format errata which I'm sure caused DKIM1
early adopters trouble.  Without native support in the popular crypto
libraries (OpenSsl, BouncyCastle, BoringSsl, Tink to name a few) for
mldsa44-ed25519-sha512, email operators will have to implement their own
composite implementation, introducing interoperability and security risks.
Keep in mind that the long term goal for DKIM2 is to make these algorithms
mandatory to implement as noted in Section 3.3 in that draft.

I agree with John that stopping signing with a vulnerable algorithm is a
reasonable solution.  If breakage of classical signature algorithms is
imminent because of a Cryptographically  Relevant Quantum Computer (CRQC),
I suspect that there will be warnings with rumors and research papers
thrown about.  Also as John points out, email won't be the first target of
actors with access to CRQCs.  What's more important is creating an
ecosystem with the agility to pivot if there is a warning.  As noted above,
the draft calls for an eventual mandatory implementation timeline in
Section 3.3 which hopefully will help. On the other hand, if that
mandatory-to-implement requirement is too onerous, it becomes a barrier to
deploying DKIM2. Thus I think we should start with three algorithms: RSA,
Ed25519, and ML-DSA-44 as they all have native support in the major crypto
libraries.

> My impression is also that
>
> a) I'm not sure how likely it is in the first place for quantum attacks to
> become practical at all
>
> b) Even if they do so, I'd guess they'll stay very expensive for yet more
> time
>
> c) I'd agree with you that DKIM keys won't be extra high on the priority
> list of those operating such machines.
>
+1

> However, I'd like to add something:
>
> "[...] DKIM signatures [...] short lived [...]"
>
> I think this might miss the point a little. As far as I understand, the
> potential quantum attacks would probably be against the keys. So the effort
> isn't proportional to the number of signatures one would like to fake, but
> only to the number of keys involved.
>
> So so for sites with long-lived DKIM keys (much mail traffic with the same
> key), the effort/costs would be amortized over a much larger number of
> mails (or faked mails) than for sites with short-lived DKIM keys.
>
> So a partial mitigation of potential quantum attacks even without
> employing PQ algorithms would be rotating keys daily (removing old keys
> from DNS after 14 days). Then a potential quantum attacker would get even
> less value for the effort/costs.
>
> 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.
>
> After my mail suggesting such a combined algorithm, I read some rationales
> against them too (in favor of using one of the PQ algorithms "purely"). But
> then this would still leave us the way to decide to specify both a "pure"
> PQ algorithm, and a ed25519+PQ (concatenation based) algorithm.
>
> A bit orthogonal to that is the discussion we're still having elsewhere
> how to go on with the current spec ambiguities about multiple signature
> entries.
>
> But regardless which direction, I'd not like algorithm specific special
> rules like "in this combination it's AND, otherwise it's OR".
>
Currently multiple signatures for a given DKIM2-signature header field are
supposed to be evaluated with an "OR".  Removing vulnerable signatures on
warning is one approach.  Another approach could be to have a signature tag
that toggles the "OR" evaluation to "AND" which is more flexible but more
complex.  Both approaches allow the signer to evaluate the effects of
deploying new algorithms.
-Wei

> [...]
>
> 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.
>
> IMO not completely.
>
> 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.
>
> I'm not sure about this.
>
> IIRC an ED25519 key is 256 or 257 bits, i.e. 43 base64 characters.
>
> A 2048 bit RSA key is those 2048 bits plus a bit for the 17 bit exponent.
> That is 345 base64 characters, i.e. already needs (at least) two
> at-most-255-char "entries" in the TXT record.
>
> But I've seen elsewhere in the discussion that it might be reasonable that
> even an ML-DSA-44 key would still be at least bearable with 1750 base64
> characters.
>
> Hannah.
>
> --
> Hannah Stern
>
> Software Developer
> Mail Transfer Development
>
> 1&1 Mail & Media Development & Technology GmbH |  |   |
> Phone: [phone] <+49%20721%20913744519>
> E-Mail: [e-mail] | Web: www.mail-and-media.com www.gmx.net www.web.de www.mail.com www.united-internet-media.de
>
> Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452
>
> Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Thomas Ludwig, Dr. Verena Patzelt
>
>
> Member of United Internet
>
> Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden.
>
> This e-mail may contain confidential and/or privileged information. If you are not the intended recipient of this e-mail, you are hereby notified that saving, distribution or use of the content of this e-mail in any way is prohibited. If you have received this e-mail in error, please notify the sender and delete the e-mail.
>
> _______________________________________________
> Ietf-dkim mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>