On Sun, Aug 25, 2024 at 12:07:34PM -0400, pgnd wrote:
I'm using dane "3 1 2" records; all checks are good.
Which domain(s)?
I note LE's current Chain of Trust currently are
roots: ISRG Root X1: RSA 4096, until 2030-06-04 (generated 2015-06-04)
See below, X1 is presently set to expire in 2035.
ISRG Root X2: ECDSA P-384, until 2035-09-04 (generated 2020-09-04)and
intermediates: Let’s Encrypt E5: ECDSA P-384, until 2027-03-12 Let’s Encrypt E6: ECDSA P-384, until 2027-03-12 Let’s Encrypt R10: RSA 2048, until 2027-03-12 Let’s Encrypt R11: RSA 2048, until 2027-03-12
(plus 3 backups for each pair)
to date, my cert generation has had
DEFAULT_PREFERRED_CHAIN='ISRG Root X1'
, i.e. RSA.
Yes, The root is RSA, but in many cases the underlying chain is ECDSA, There are two versions of E5..9 certs, with one signed by X1 and the other by X2.
_25._tcp.mail.censored.example. IN TLSA 2 1 1 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3 _25._tcp.mail.censored.example. IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d mail.censored.example[192.0.2.1]: pass: TLSA match: depth = 2, name = mail.censored.example TLS = TLS13 with AES256GCM-SHA384,X25519,PubKeyALG_EC name = mail.censored.example depth = 0 Issuer CommonName = E5 Issuer Organization = Let's Encrypt notBefore = 2024-08-16T19:30:03Z notAfter = 2024-11-14T19:30:02Z Subject CommonName = mail.censored.example pkey sha256 [nomatch] <- 3 1 1 8fb34b1f452c2acba0e9c418defd705f09b9abf6006da7bfc6deafa5149bf7f2 depth = 1 Issuer CommonName = ISRG Root X1 Issuer Organization = Internet Security Research Group notBefore = 2024-03-13T00:00:00Z notAfter = 2027-03-12T23:59:59Z Subject CommonName = E5 Subject Organization = Let's Encrypt pkey sha256 [nomatch] <- 2 1 1 3586d4ecf070578cbd27aedce20b964e48bc149faeb9dad72f46b857869172b8 depth = 2 Issuer CommonName = ISRG Root X1 Issuer Organization = Internet Security Research Group notBefore = 2015-06-04T11:04:38Z notAfter = 2035-06-04T11:04:38Z Subject CommonName = ISRG Root X1 Subject Organization = Internet Security Research Group pkey sha256 [matched] <- 2 1 1 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3
Note that the 2nd TLSA RR in the above (lightly anonymised) example has a digest matching R3, rather than E5. It still works via X1, but it is fair to assume that the operator intended for both TLSA records to be effective. A more robust TLSA RRset based on LE's CAs would list both X1 and X2, and then E5..E9:
X1: IN TLSA 2 1 1 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3 X2: IN TLSA 2 1 1 762195c225586ee6c0237456e2107dc54f1efc21f61a792ebd515913cce68332 E5: IN TLSA 2 1 1 3586d4ecf070578cbd27aedce20b964e48bc149faeb9dad72f46b857869172b8 E6: IN TLSA 2 1 1 d016e1fe311948aca64f2de44ce86c9a51ca041df6103bb52a88eb3f761f57d7 E7: IN TLSA 2 1 1 cbbc559b44d524d6a132bdac672744da3407f12aae5d5f722c5f6c7913871c75 E8: IN TLSA 2 1 1 885bf0572252c6741dc9a52f5044487fef2a93b811cdedfad7624cc283b7cdd5 E9: IN TLSA 2 1 1 f1440a9b76e1e41e53a4cb461329bf6337b419726be513e42e19f1c691c5d4b2
and, I publish both RSA and ECDSA DANE records.
If you also have both certificate algorithms deployed live on your server keep in mind that you then need two sets of "3 1 1" records, one for each algorithm:
https://mail.sys4.de/pipermail/dane-users/2017-August/000416.html
a switch to ECDSA
DEFAULT_PREFERRED_CHAIN='ISRG Root X2'
should be (?) reasonably well tolerated.
i'm unclear on
is it DANE-safe? or DANE-recommended?
Yes, though it is in principle possible that there are DANE-enabled senders that support only RSA, and then might not be able to send you mail. At this point in time, that'd be the hypothetical sender's fault, they'd have little excuse to not support ECDSA. I don't know whether the problem is real or how prevalent it might be.
Simpler to stick with RSA for now, there's little reason to be worried about brute-force attacks on 2048-bit RSA keys, and email servers serve a lot fewer connections per second than HTTP servers, so the bandwidth and CPU differences are not significant.
I have no experience using Let's Encrypt (perhaps some ACME clients make this easier than others) with simultaneous RSA and ECDSA certs for the same hostname.