On Thu, Dec 14, 2023 at 11:04:32AM +0100, Joachim Lindenberg via Postfix-users
wrote:
> I´d say Viktor is biased towards 3 1 1.
It isn't a bias, it is a rational recommendation. There are multiple
issues with "2 1 1":
- With a public issuer CA, you're adding a redundant trusted party,
with generally rather weak domain validation (DV) certificate
issuance mechanisms.
- The underlying EE certificates are then subject to periodic
expiration. Some operators invariably fail to rotate them
on time.
- A less common problem, but also unique to DANE-TA(2) is failure to
match the hostname in the certificate. Some operators neglect to
make sure that the TLSA base domain aligns with a DNS name in the
certificate.
- The CA operator can always surprise you with unexpected changes in
their insfrastructure.
- With "3 1 1" *you* decide when to rotate your keys, pre-publish
a "3 1 1" TLSA record matching next key, and then switch to that
key once the TLSA record has been in place for a few TTLs.
> You may call me biased towards 2 1 1 because I dislike pinning a key
> that is supposed to rotate.
You're always pinning a key, either the issuer CA's or the end-entity
(EE) servers. Only poor ACME tooling gets in the way of key rotation
with "3 1 1".
If you can prepare a key in advance of a certificate rollover,
prepublish the matching "3 1 1" and use that key conditionally on a
prepublication timer having elapsed, then you get key rollover without
introducing a redundant trusted third party or risking outages due to
certificate expiration, name match failures, ...
Each day, a handful of domains fail DANE validation, a large majority,
because of botched Let's Encrypt integration, where the key rotation
is not properly orchestrated. They'd be far better off with a "pinned"
3 1 1, that they rollover at their discretion, rather than let the
ACME client break their mail system every 2 months.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
