On Thu, Jan 29, 2026 at 10:18:34AM -0500, pgnd via Postfix-users wrote: > the CA's root/intermediate are PQC algo signed.
When you say "PQC", you need to be more specific. Do you mean one of "ML-DSA-65", "ML-DSA-44" or "ML-DSA-87"? Or something else? Those are presently the only PQC signature algorithms supported at OpenSSL TLS layer, requiring OpenSSL 3.5 or later. > internally, PQC is now used for local-only/internal self-signed ssl. ML-KEM key exchange? ML-DSA TLS server/client public keys? Or both? > iiuc, PQC for public-facing LE & DNSSEC in general is early-days, > > https://www.ietf.org/archive/id/draft-sheth-pqc-dnssec-strategy-00.html DNSSEC is going to be a late adopter of PQC. Why are you bringing up DNSSEC? I thought you wanted PQC signatures in TLS? > what part does/can PQC yet play 'in' Postfix? ML-KEM key exchange works out of the box. When compiled against a sufficiently recent OpenSSL (3.5 or later), Postfix 3.11 defaults to: $ postconf -d tls_eecdh_auto_curves tls_ffdhe_auto_groups tls_eecdh_auto_curves = ?X25519MLKEM768:DEFAULT tls_ffdhe_auto_groups = which negotiates ML-KEM with compatible servers after a Hello Retry Request (HRR), because sending unsolicited ML-KEM keyshares for now occasionally (not quite negligibly often) runs into friction with middle-boxes that fail to handle TLS Client Hello messages that don't fit into a single TCP frame. Also, when compiled against OpenSSL 3.5 or later, ML-DSA is supported by default, but it is up to server whether which certificate type to offer when more than one type is configured and the client supports more than one. That's up tot he ordering of "SignatureAlgorithms" in the server's "openssl.cnf" file. Since my server has only RSA and ML-DSA-65 (known as "mldsa65" as a TLS-layer signature algorithm) certificates, I have: SignatureAlgorithms = mldsa65:rsa_pss_rsae_sha256:rsa_pss_rsae_sha384:rsa_pss_rsae_sha512:rsa_pkcs1_sha256:rsa_pkcs1_sha384:rsa_pkcs1_sha512:rsa_pkcs1_sha1 > too early for public-facing 'smtpd_tls_chain_files', i assume? Actually, ML-DSA-65 works just fine for me, because clients that don't support ML-DSA won't offer it as a supported algorithm and are either doing DANE or opportunistic TLS anyway, while{ DANE "3 1 1" records don't care about having a CA-issued certificate. So you too can probably get away with public facing ML-DSA certs, unless you publish an MTA-STS policy, because in that case some clients that support MTA-STS but haven't explicitly turned off ML-DSA support might fail to authenticate your self-signed or privately-issued ML-DSA certs. Examples (first is probably Postfix, given support for raw public keys): Jan 08 22:47:59 amnesiac postfix/smtpd[2759796]: Anonymous TLS connection established from mout-a1.edge-mail.de[2a03:4000:20:278:465::1]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ML-DSA-65 (raw public key) Jan 29 01:19:38 amnesiac postfix/smtpd[3786749]: Anonymous TLS connection established from cumin.exim.org[2a00:11c0:5f:34c1::2]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519MLKEM768 server-signature ML-DSA-65 (The postmaster of the first server did not know to override the compiled-in default key exchange groups in a slightly older Postfix). That said, it is mostly an "eat own dogfood" exercise, there's really little benefit other than test-driving the technology as a developer. > what about internal use between non-public-facing/internal pfx > instances? Your choice. > my impression is -- leave any/all public-facing pfx crypto alone/as-is > for now, but that internal relays might be ok ... ? See above, with MTA-STS best to be careful, otherwise you should be fine (provided DANE TLSA records are absent or also match any ML-DSA cert). -- Viktor. 🇺🇦 Слава Україні! _______________________________________________ Postfix-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
