dane-users

Download

dane-users@list.sys4.de

June 2025

2 participants
2 discussions

Pruning outdated TLSA DANE-EE(3) records
by Viktor Dukhovni 23 Jun '25

23 Jun '25

Some MTA operators neglect to prune outdated TLSA records with "usage" DANE-EE(3). As keys or certificates are replaced, they add new matching TLSA records, never dropping the records matching the outdated keys. This largely defeats the purpose of key or certificate rollover, since it blesses (at least in the context of DANE) ongoing misuse of any past compromise of the old key. And it results in ever growing TLSA records DNS payload sizes, resulting initially in needlessly large UDP payloads, and ultimately failover to TCP for every lookup. It is best to avoid this pattern and prune outdated TLSA records once the corresponding key (3 1 X) or certificate (3 0 X) is no longer in use. Example (current DANE-EE(3) count record holder): _25._tcp.mail.evocat.net TLSA 3 1 1 83037f6a136945f50dbc4e4cb65d0c154b726992eafb55ba5b3b4e4bcbde9715 ; 2022-05-27 - present _25._tcp.mail.evocat.net TLSA 3 1 1 379f309bff870568b06756c3ccb321692fdde8e970950ca0cbae3b4595e5b538 ; 2022-07-27 - present _25._tcp.mail.evocat.net TLSA 3 1 1 a31fdc67764edc9e7bc734b907bd8b514f4616d2e8e2dfbcb01c8dc557acea34 ; 2022-09-25 - present _25._tcp.mail.evocat.net TLSA 3 1 1 21e1d9438b6528948794244cf1caf5802c6edb5a3415d33d7299c7daadee3834 ; 2022-11-24 - present _25._tcp.mail.evocat.net TLSA 3 1 1 c7be1ef02c2556cf4f421cb724b0327676d2d144790042a3aa603dfc96fb4a5a ; 2023-01-23 - present _25._tcp.mail.evocat.net TLSA 3 1 1 8115a64ccf2aa3b7e06c2e0cab0b972ca98eb83c707b68fc725c02195ce8d47f ; 2023-03-25 - present _25._tcp.mail.evocat.net TLSA 3 1 1 37c12ea11d4cd88c756768308a13587ebdd4fe626f7dc2512e37c85d1fe20d14 ; 2023-05-24 - present _25._tcp.mail.evocat.net TLSA 3 1 1 196d17a19f5dc1c0ad4a58eb8afff5e07b92ba72cd6d776b941e4233856c0636 ; 2023-07-24 - present _25._tcp.mail.evocat.net TLSA 3 1 1 3b3ee102ccb95a75ca73b337b4ba88d33b3cff3b1a2309227d71ccd808144482 ; 2023-09-22 - present _25._tcp.mail.evocat.net TLSA 3 1 1 e896a20362f25d49a869f12ff99878b86e37dc86af38c04c29ab8992a6502f30 ; 2023-11-21 - present _25._tcp.mail.evocat.net TLSA 3 1 1 7475c707cdf5137eea74ea02f23b81ede7a1b4d2edb65af08c8cc1749a3f5c99 ; 2024-01-21 - present _25._tcp.mail.evocat.net TLSA 3 1 1 e5949d3fb74344210439161d7bf2fb53e0bc68fe74a1e21a870c8881fbcd5901 ; 2024-03-21 - present _25._tcp.mail.evocat.net TLSA 3 1 1 31ea43c1733770793b157aa8963a2fc3dfc969ad3c6849c31d33e14ff643615e ; 2024-05-20 - present _25._tcp.mail.evocat.net TLSA 3 1 1 87e19f49bf9fae3273509940f27931dcf2edd3fc132eb1f2ddbe56e2bc2e0410 ; 2024-07-19 - present _25._tcp.mail.evocat.net TLSA 3 1 1 a0c849a30b9cf92c206a28723324ed40318a7e2a82e56104959588a795db3669 ; 2024-09-19 - present _25._tcp.mail.evocat.net TLSA 3 1 1 468e0e2e119ea97bc8ab3c34792fa479dd8ea2d47e62a868020e06dc3d25c304 ; 2024-11-17 - present _25._tcp.mail.evocat.net TLSA 3 1 1 d6fffb71e83fcec0dde93edbbc1c50b0fdff21dffc78390c309c1cf3dd350370 ; 2025-01-16 - present _25._tcp.mail.evocat.net TLSA 3 1 1 a2cb82878da95d9bae063340e6312ab7fe85100671899bf13793dc8893e42ac9 ; 2025-03-17 - present _25._tcp.mail.evocat.net TLSA 3 1 1 e4ccf3f074a06cd30722fc42df127ef8e682136b40116e6bb77adf9679140f2f ; 2025-05-16 - present The authoritative DNS server returns a truncated (TC=1) response, leading to TCP fallback and high, from my vantage point, latency: $ dig @ns1.evocat.net +norecur +dnssec +noall +stats -t tlsa _25._tcp.mail.evocat.net ;; Query time: 1014 msec ;; SERVER: 185.157.233.76#53(ns1.evocat.net) (TCP) ;; WHEN: Mon Jun 23 04:03:04 UTC 2025 ;; MSG SIZE rcvd: 2886 By way of comparison, the "A" RRset response fits in UDP and the latency I see is 5x lower: $ dig @ns1.evocat.net +norecur +dnssec +noall +stats -t a mail.evocat.net ;; Query time: 201 msec ;; SERVER: 185.157.233.76#53(ns1.evocat.net) (UDP) ;; WHEN: Mon Jun 23 04:04:55 UTC 2025 ;; MSG SIZE rcvd: 1106 -- Viktor.

2 3

TLSA record hygiene for Let's Encrypt issuer CAs
by Viktor Dukhovni 15 Jun '25

15 Jun '25

[ Please read carefully, this post covers multiple Let's Encrypt-related topics ] Some SMTP server operators have chosen to publish DANE TLSA records for their MX hosts that match one or more of the Let's Encrypt issuer CAs: https://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html#cas The "2 1 1" RRset to match one of R10–R14 should list them all, because certificate renewal randomly chooses of the active CAs (currently R10 and R11, but could as needed be one of the R12–R14 backups): _25._tcp.mx.some.example. 2 1 1 2bbad93ab5c79279ec121507f272cbe0c6647a3aae52e22f388afab426b4adba ; R10 _25._tcp.mx.some.example. 2 1 1 6ddac18698f7f1f7e1c69b9bce420d974ac6f94ca8b2c761701623f99c767dc7 ; R11 _25._tcp.mx.some.example. 2 1 1 919c0df7a787b597ed056ace654b1de9c0387acf349f73734a4fd7b58cf612a4 ; R12 _25._tcp.mx.some.example. 2 1 1 025490860b498ab73c6a12f27a49ad5fe230fafe3ac8f6112c9b7d0aad46941d ; R13 _25._tcp.mx.some.example. 2 1 1 f1647a5ee3efac54c892e930584fe47979b7acd1c76c1271bca1c5076d869888 ; R14 The "2 1 1" RRset to match one of E5–E9 should list them all, because certificate renewal randomly chooses of the active CAs (currently E5 and E6, but could as needed be one of the E7–E9 backups): _25._tcp.mx.some.example. 2 1 1 3586d4ecf070578cbd27aedce20b964e48bc149faeb9dad72f46b857869172b8 ; E5 _25._tcp.mx.some.example. 2 1 1 d016e1fe311948aca64f2de44ce86c9a51ca041df6103bb52a88eb3f761f57d7 ; E6 _25._tcp.mx.some.example. 2 1 1 cbbc559b44d524d6a132bdac672744da3407f12aae5d5f722c5f6c7913871c75 ; E7 _25._tcp.mx.some.example. 2 1 1 885bf0572252c6741dc9a52f5044487fef2a93b811cdedfad7624cc283b7cdd5 ; E8 _25._tcp.mx.some.example. 2 1 1 f1440a9b76e1e41e53a4cb461329bf6337b419726be513e42e19f1c691c5d4b2 ; E9 Users whose MX hosts have both ECDSA and RSA certificates from Let's Encrypt, or who are switching between RSA and ECDSA keys (unclear to me whether or under what conditions this can happen automatically) may need to list all 10 intermediate CA RRs. Some operators have chosen to publish TLSA records matching the ISRG Root CAs that are the issuers of the above intermediate certs. The "2 1 1" records for these are: 2 1 1 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3 ; ISRG X1 (RSA 4096-bit) 2 1 1 762195c225586ee6c0237456e2107dc54f1efc21f61a792ebd515913cce68332 ; ISRG X2 (ECDSA P384) The R10–R14 intermediate CA certificates are issued by "ISRG X1", while the E5–E9 intermediate CA certificates are issued by "ISRG X2". Though the root issuer is presently stable for a given server key type (RSA or ECDSA), I still recommend listing them both when listing either. More critically, when listing the root CAs, the operator MUST make sure to include the root CA certificate in the server's configured chain file. Listing just the EE + intermediate cert (or sometimes just the EE cert) is not sufficient. See: https://datatracker.ietf.org/doc/html/rfc7671#section-5.2.2 https://datatracker.ietf.org/doc/html/rfc7671#section-5.2.3 And of course when using "DANE-TA(2) X X" TLSA records, the server's EE certificate MUST be part of a chain with at least the intermediate CA certs. It is also essential to keep track of periodic changes in the set of CAs used by the Let's Encrypt. As currently listed at: https://letsencrypt.org/certificates/ and periodically announced on their blog, e.g.: https://letsencrypt.org/2024/04/12/changes-to-issuance-chains/ In relation to keep track, I want to mention that a small, but non-trivial fraction of DANE MTA operators have failed to remove already long-retired CAs from their TLSA records (or, in a few cases, even switch from these to the active CAs!). These records SHOULD be removed. See https://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html https://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html#mxhosts These include: - 1 MX hosts publishing X1 (DST root): IN TLSA 2 0 1 7fdce3bf4103c2684b3adbb5792884bd45c75094c217788863950346f79c90a3 subject=C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1 issuer=O=Digital Signature Trust Co., CN=DST Root CA X3 notBefore=Oct 19 22:33:36 2015 GMT notAfter=Oct 19 22:33:36 2020 GMT - 14 MX hosts publishing X3 (DST root): IN TLSA 2 0 1 25847d668eb4f04fdd40b12b6b0740c567da7d024308eb6c2c96fe41d9de218d subject=C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3 issuer=O=Digital Signature Trust Co., CN=DST Root CA X3 notBefore=Mar 17 16:40:46 2016 GMT notAfter=Mar 17 16:40:46 2021 GMT - 57 MX hosts publishing X3: IN TLSA 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 IN TLSA 2 1 2 774fad8c9a6afc2bdb44faba8390d213ae592fb0d56c5dfab152284e334d7cd6abd05799236e7aa6266edf81907c60404c57ee54c10a3a82fcc2a9146629b140 subject=C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3 issuer=C=US, O=Internet Security Research Group, CN=ISRG Root X1 notBefore=Oct 6 15:43:55 2016 GMT notAfter=Oct 6 15:43:55 2021 GMT - 14 MX hosts publishing X4: IN TLSA 2 1 1 b111dd8a1c2091a89bd4fd60c57f0716cce50feeff8137cdbee0326e02cf362b subject=C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X4 issuer=C=US, O=Internet Security Research Group, CN=ISRG Root X1 notBefore=Oct 6 15:44:34 2016 GMT notAfter=Oct 6 15:44:34 2021 GMT - 398 MX hosts publishing R3: IN TLSA 2 0 1 67add1166b020ae61b8f5fc96813c04c2aa589960796865572a3c7e737613dfd IN TLSA 2 0 2 96c5793b2b57d8df5891c94015720960e0da4c2cf8ce1fc5707a0b46e5db8ce3761fb5fdb430f619d1579f13e80fbdd973ef6a024129ed039aa193273158fcad IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d IN TLSA 2 1 2 0f644c9a1dcb8c04be6b385a60dbe4fdf7e2b81e335c9ad8c7cd0abe2ff9e7e5bbfbb68b38dd0216f17808f48bdf6af8c6347659c1f41a9858032c31f436d12c subject=C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X4 issuer=C=US, O=Internet Security Research Group, CN=ISRG Root X1 notBefore=Oct 6 15:44:34 2016 GMT notAfter=Oct 6 15:44:34 2021 GMT - 134 MX hosts publishing R4: IN TLSA 2 0 1 1a07529a8b3f01d231dfad2abdf71899200bb65cd7e03c59fa82272533355b74 IN TLSA 2 1 1 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 IN TLSA 2 1 2 59a91d97d81980951d0ef3c6d849b31606af9ab2b0f7dcfac93a53ae3263eb8902c3b7c564f33ff496f2d07c750b1b6924968c243882af9e3532797eef596f27 subject=C=US, O=Let's Encrypt, CN=R4 issuer=C=US, O=Internet Security Research Group, CN=ISRG Root X1 notBefore=Sep 4 00:00:00 2020 GMT notAfter=Sep 15 16:00:00 2025 GMT - 125 MX hosts publishing E1 IN TLSA 2 1 1 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 IN TLSA 2 1 2 3561540fbf182bce7749acc131b421e691f083569c053e78f20274714c5e801226ff6edb60641ddf70e71bd3a90dfe25ddd6464be78106b77dece4f6a3bff13d subject=C=US, O=Let's Encrypt, CN=E1 issuer=C=US, O=Internet Security Research Group, CN=ISRG Root X2 notBefore=Sep 4 00:00:00 2020 GMT notAfter=Sep 15 16:00:00 2025 GMT - 100 MX hosts publishing E2 IN TLSA 2 1 1 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 IN TLSA 2 1 2 23a30bd3b617652e97224e1faf673c4e09f1c197e4994274e676f2490893e9560d99f00a8859e399b2c65219ce2eb9b76784a0ec775ab4973a14fc1437ac7d9f subject=C=US, O=Let's Encrypt, CN=E2 issuer=C=US, O=Internet Security Research Group, CN=ISRG Root X2 notBefore=Sep 4 00:00:00 2020 GMT notAfter=Sep 15 16:00:00 2025 GMT - 2 MX hosts publishing the long expired cross-signed by DST ISRG Root X1: IN TLSA 2 0 1 6d99fb265eb1c5b3744765fcbc648f3cd8e1bffafdc4c2f99b9d47cf7ff1c24f subject=C=US, O=Internet Security Research Group, CN=ISRG Root X1 issuer=O=Digital Signature Trust Co., CN=DST Root CA X3 notBefore=Jan 20 19:14:03 2021 GMT notAfter=Sep 30 18:14:03 2024 GMT -- Viktor.

1 0