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.
--
Viktor.
