4 ms·

Ed25519 has seen broad adoption in TLS and other stacks that are used pervasively where DKIM is also used. What’s blocking it for DKIM uniquely? (This isn’t in

Ed25519 has seen broad adoption in TLS and other stacks that are used pervasively where DKIM is also used. What’s blocking it for DKIM uniquely? (This isn’t intended as a leading question.)

daneel_w 2y ago
Everyone has to be onboard before the switch can be made, and not everyone is happy about the somewhat messy solution of running dual-stack RSA+Ed25519 setups in the interim - it's a bit different than e.g. supporting multiple methods for key exchange or multiple ciphers for symmetric crypto. It's just one of those things that take time to happen.
- bluGill 2y ago
  If the big players (gmail, outlook) jump onto it the rest will be forced to follow. Outlook would probably jump in with a checkbox, and perhaps gmail will make at an option for the paid tier while everyone on the free tier gets no choice - but that is still enough. SmallCompany.com cannot do it alone, probably not even a fortune100.com (if any of them even care - their sales staff probably will overrule the few who do), but there are enough players if they all agree on something. Getting the big players to agree and execute though is a lot like herding cats. I'm sure some in the big players are trying.
- deleted 2y ago
  [deleted]
paulnpace 2y ago
> What’s blocking it for DKIM uniquely? Mail server administrators.
Avamander 2y ago
X25519 has seen broad adoption (in the key exchange). Ed25519 has not, you can't actually use an Ed25519 certificate on the web. It's in a deadlock between CAs, browsers and TPM manufacturers (and to some extent NIST, because Ed25519 has not been approved by them). It's not being blocked per se, you can use it mostly (98%) without any issues. Though things like Amazon SES incorrectly reject letters with multiple signatures. Google and Microsoft can't validate them when receiving. It's more that a few common implementations lack the support for them so you can't use _just_ Ed25519.
- throw0101c 2y ago
  > (and to some extent NIST, because Ed25519 has not been approved by them). Ed25519 (and Ed448) have been approved for use in FIPS 186-5 as of February 2023: * https://en.wikipedia.org/wiki/EdDSA#Standardization_and_implementation_inconsistencies https://en.wikipedia.org/wiki/EdDSA#Standardization_and_impl...
  - Avamander 2y ago
    Oh, great to know. That gives me hope that we'll see Ed25519 certificates at some point then.
    - brohee 2y ago
      THE CABForum just updated its guidelines (in December) and elliptic curve wise only NIST P-256, NIST P-384 and NIST P-521 are accepted. (See https://cabforum.org/working-groups/server/baseline- https://cabforum.org/working-groups/server/baseline- requirements/requirements/#615-key-sizes) So on the general web it seems remote at best.
      - throw0101c 2y ago
        > THE CABForum just updated its guidelines (in December) and elliptic curve wise only NIST P-256, NIST P-384 and NIST P-521 are accepted. NIST P-curve certs were acceptable per the Base Requirements all the way back in 2012 * https://cabforum.org/uploads/Baseline_Requirements_V1_1.pdf https://cabforum.org/uploads/Baseline_Requirements_V1_1.pdf See "Appendix A - Cryptographic Algorithm and Key Requirements (Normative)", (3) Subscriber Certificates.
        brohee 2y ago
        I'm well aware I should have added a "still" in the sentence somewhere. All efforts to have Ed25519 on the general web seem to run out of steam, we can find https://www.ietf.org/archive/id/draft-moskowitz-eddsa-pki-06.html https://www.ietf.org/archive/id/draft-moskowitz-eddsa-pki-06... IETF side, https://lists.cabforum.org/pipermail/servercert-wg/2024-June/004646.html https://lists.cabforum.org/pipermail/servercert-wg/2024-June... is the last discussion CABforum side. Ed25519 certs do work with TLS (OpenSSL support at least), but without browser adoption it's machine to machine with private CA only .

Ed25519 has seen broad adoption in TLS and other stacks that are used pervasively where DKIM is also used. What’s blocking it for DKIM uniquely? (This isn’t intended as a leading question.)

daneel_w 2y ago

Everyone has to be onboard before the switch can be made, and not everyone is happy about the somewhat messy solution of running dual-stack RSA+Ed25519 setups in the interim - it's a bit different than e.g. supporting multiple methods for key exchange or multiple ciphers for symmetric crypto. It's just one of those things that take time to happen.

bluGill 2y ago
If the big players (gmail, outlook) jump onto it the rest will be forced to follow. Outlook would probably jump in with a checkbox, and perhaps gmail will make at an option for the paid tier while everyone on the free tier gets no choice - but that is still enough. SmallCompany.com cannot do it alone, probably not even a fortune100.com (if any of them even care - their sales staff probably will overrule the few who do), but there are enough players if they all agree on something. Getting the big players to agree and execute though is a lot like herding cats. I'm sure some in the big players are trying.
deleted 2y ago
[deleted]

paulnpace 2y ago

> What’s blocking it for DKIM uniquely? Mail server administrators.

Avamander 2y ago

X25519 has seen broad adoption (in the key exchange). Ed25519 has not, you can't actually use an Ed25519 certificate on the web. It's in a deadlock between CAs, browsers and TPM manufacturers (and to some extent NIST, because Ed25519 has not been approved by them). It's not being blocked per se, you can use it mostly (98%) without any issues. Though things like Amazon SES incorrectly reject letters with multiple signatures. Google and Microsoft can't validate them when receiving. It's more that a few common implementations lack the support for them so you can't use _just_ Ed25519.

throw0101c 2y ago
> (and to some extent NIST, because Ed25519 has not been approved by them). Ed25519 (and Ed448) have been approved for use in FIPS 186-5 as of February 2023: * https://en.wikipedia.org/wiki/EdDSA#Standardization_and_implementation_inconsistencies https://en.wikipedia.org/wiki/EdDSA#Standardization_and_impl...
- Avamander 2y ago
  Oh, great to know. That gives me hope that we'll see Ed25519 certificates at some point then.
  - brohee 2y ago
    THE CABForum just updated its guidelines (in December) and elliptic curve wise only NIST P-256, NIST P-384 and NIST P-521 are accepted. (See https://cabforum.org/working-groups/server/baseline- https://cabforum.org/working-groups/server/baseline- requirements/requirements/#615-key-sizes) So on the general web it seems remote at best.
    - throw0101c 2y ago
      > THE CABForum just updated its guidelines (in December) and elliptic curve wise only NIST P-256, NIST P-384 and NIST P-521 are accepted. NIST P-curve certs were acceptable per the Base Requirements all the way back in 2012 * https://cabforum.org/uploads/Baseline_Requirements_V1_1.pdf https://cabforum.org/uploads/Baseline_Requirements_V1_1.pdf See "Appendix A - Cryptographic Algorithm and Key Requirements (Normative)", (3) Subscriber Certificates.
      - brohee 2y ago
        I'm well aware I should have added a "still" in the sentence somewhere. All efforts to have Ed25519 on the general web seem to run out of steam, we can find https://www.ietf.org/archive/id/draft-moskowitz-eddsa-pki-06.html https://www.ietf.org/archive/id/draft-moskowitz-eddsa-pki-06... IETF side, https://lists.cabforum.org/pipermail/servercert-wg/2024-June/004646.html https://lists.cabforum.org/pipermail/servercert-wg/2024-June... is the last discussion CABforum side. Ed25519 certs do work with TLS (OpenSSL support at least), but without browser adoption it's machine to machine with private CA only .