On Thu, Jun 26, 2025 at 07:46:47PM +0000, Fehlauer, Norbert via mailop wrote:
> Just want to ask if there is a best practice DANE handling when not
> using automatism but "normal" 1 year public certificates.
The best-practice approach is independent of whether rollover is
frequent and automated or infrequent and somewhat manual. The only
difference is that manual informal processes performed infrequently are
likely to randomly deviate from that best practice, because of lack
of documentation, attention to detail, ...
> Usually 3 1 1 for the actual used certificate is fine. But having a
> rollover scheme is something I don't fully understand.
If certificate renewal leaves the key unchanged, and only the dates,
serial number, ... change. Then a TLSA RRset with "3 1 1" records does
not require any upkeep. If the key is changing, then regardless of
whether the process is automated or manual, the correct order of events
is:
1. Generate a new key.
2. Publish an **additional** TLSA "3 1 1" record matching that key,
alongside any TLSA "3 1 1" records matching the current live
key(s) (sometimes live keys plural, for multiple algorithms, say
ECDSA and RSA).
3. Wait a few additional DNS TTLs after all secondary DNS servers
have updated their copy of the zone, and are publishing the
new TLSA RRset.
4. Deploy the new key and certificate chain.
- The certificate chain can be generated any time after or as part of
step 1, but MUST NOT be deployed prior to the completion of step 3.
- That is you must *delay* its deployment if generated prior to
step 3.
5. After all affected MTAs are responding with only the new
certificate chain(s) (multiple algorithms?), purge stale
TLSA "3 1 1" records matching *retired* key from the TLSA
RRset.
One way to approach this:
https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html
> Should I use the 2 0 1 Trust Anchor of the actual used certificate or
> should I only publish another 3 1 1 record as soon as I get the next
> certificate (usually a few days before the first one expires).
See above, there's no need for DANE-TA(2) TLSA records during a
rollover, but TLSA updates SHOULD NOT be deferred to coincide with or
follow the certificate deployment, that way you get intermittent or
longer outages.
--
Viktor.
On Thu, Jun 26, 2025 at 09:28:54PM +0000, Fehlauer, Norbert via mailop wrote:
> But when using only 3 1 1 dane records I can only publish the new
> certificate as soon as it is signed. And going to delete the old
> record a few days later.
Well, definitely not before, but deployment can and should be delayed,
if necessary, to allow time for stale TLSA records to expire from
secondary DNS servers and downstream resolver caches.
> Taking https://en.internet.nl/mail/ recommendation this would than
> never "meet the" the recommendation except for the few days where two
> TLSA records exists (usually a few days overlapping).
Their recommendation of *always* having two records published is
somewhat misguided. It is based on the proactive approach in:
https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html
but it is fine to generate the new key "just in time", provided you
still publish TLSA record first, and roll the cert some TTLs later.
> We recommend you to apply one of the following two schemes with double
> DANE TLSA records:
>
> Current + Next ("3 1 1" + "3 1 1"): Publish two "DANE-EE(3) SPKI(1)
> SHA2-256(1)" records, one for the current and one for the next TLS
> certificate of your mail server.
> Current + Issuer CA ("3 1 1" + "2 1 1"): Publish a "DANE-EE(3) SPKI(1)
> SHA2-256(1)" record for the current TLS certificate of your mail server, and
> also a "DANE-TA(2) SPKI(1) SHA2-256(1)" record for the current root or
> intermediate certificate of the (not necessarily public) certificate
> authority.
The second scheme, somes with some loss of security if you don't control
the CA or the issuance process is weak (DV domain control checks for
example). It also assumes that at the time of certificate rollover yo
have checked that the issuer key is unchanged, allowing the "2 1 1"
to do briefly do the "heavy lifting" until a new "3 1 1" comes into
effect.
This is a sort "leapfrog" scheme, where when exactly one of the keys
underlying the "3 1 1" or "2 1 1" records changes, you're relying on
the other to still be valid. If you're careless and deploy a
certificate where both changed, you're out of luck.
I recommend the pure "3 1 1" approach, but "3 1 1 + 2 1 1" or even
"2 1 1 + 2 1 1" alone (sometimes multiple if issuers are rotating)
is also OK, as a security/convenience tradeoff, provided you're paying
attention to issuer CA changes.
> Using self signed certificates would make it impossible to use DANE
> and MTA-STS at the same host I guess, right?
Yes.
> Btw. is 2 1 1 or 2 0 1 to prefer if it would be used?
While RFC7671 (sorry about that early mistake) suggests "2 0 X", with
the passage of time it became clear that in practice "2 1 X" is working
much more reliably for most users.
--
Viktor.
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
