Hi dprive folks,
TL;DR can we make incremental progress using TLSA as a signal?
TLSA records have been discussed here before as a signal that a name server
offers ADoT:
ns1.example. A ...
ns1.example. AAAA ...
_853._tcp.ns1.example. TLSA ....
Resolvers can probe for these records today as a signal for
fully-authenticated ADoT support and fallback to opportunistic TLS via
unilateral probing or unencrypted transport when not found. (This turns out
to be exactly the same approach RFC 7672 specifies for SMTP DANE, including
TLSA as a TLS-is-supported signal.)
Of course as discussed before name server name signals are imperfect:
1. NS records in referrals are unsigned (but NS revalidation[1] is possible
for signed children)
2. In-bailiwick queries cannot be secured (but there's no loss of privacy
when the initial referral is unencrypted, which is going to be typical
given sentiment against ADoT)
Without parent-side signals, no better scheme is possible for signals at
the name-server name. And there is no ideal solution for pure parent-side
signaling, and no consensus either.
So, given all that, TLSA seems to be an imperfect but workable
incremental step towards a fully secure solution. Future parent-side
signals can solve both of the issues above in a way that is 100% compatible
with non-parent TLSA signals.
Is anyone else interested in supporting this approach? I'm considering
writing up an I-D for this and welcome early feedback about whether or not
this might be worth adopting, at least for consideration on an
experimental basis for early adopters.
-Bob
p.s. Why not SVCB? In short it's unnecessary indirection and complexity.
TLSA is minimal and sufficient for now. And nothing prevents SVCB from
using (the same?) TLSA records in the future for TLS certificate
associations.
[1] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-ns-revalidation
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
