On 2/12/22 08:02, Dave Cridland wrote:
On Thu, 10 Feb 2022 at 04:46, Travis Burtrum <tra...@burtrum.org
We should instead specify in a best practice document for DANE+XMPP
that
only DANE-EE(3) should be supported/used.
Because?
Because as you've pointed out DANE-TA(2) has numerous downsides and
pitfalls, especially when it comes to the public federated XMPP network,
and there is just no reason for it.
1. as you and [RFC-7672] explained, DANE-TA(2) requires the *entire*
chain including the root to be served, which a) uses more bandwidth and
therefore slows down handshakes and b) most servers (rightly) do not do,
some can't even be configured to do this
2. It's an inevitable bomb with a long fuse, as [LE] explains, the
intermediate or root that get pinned in DANE-TA(2) will one day expire,
breaking anyone with that record. On the public federated XMPP network
this would be catastrophic, as all deployments would break at exactly
the same moment, we should be forbidding this in standards, not
encouraging it.
3. [RFC-7672] RECOMMENDS "DANE-EE(3) SPKI(1) SHA2-256(1)"
4. It's unclear to me with mandatory CAA records if, for example, "only
trust my connection if I have a valid cert signed by LetsEncrypt" is
even valuable at all if your CAA record already ensures no other CA can
issue a cert for your domain without losing their entire business
[RFC-7672]: https://datatracker.ietf.org/doc/html/rfc7672#section-3.1
[LE]:
https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
