On Thu 2021-12-09 19:17:53 -0500, Robert Evans wrote: > 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.)
I think you're suggesting that the recursive should hard-fail if a TLSA
record is found but it does not successfully authenticate the
authoritative.
TLSA itself doesn't include the following properties that i think we
want from a signal:
- indication of which encrypted transports (DoT or DoQ) are supported
- whether to hard-fail or not
- how to report errors
If i was an authoritative nameserver operator, i'd be concerned that
deploying such a TLSA record would cause my nameserver to become
unreachable.
The way i'd imagine deploying strict TLS safely on an authoritative is:
- indicate that i want reports about failures of encrypted transport
- signal that some encrypted transport is available (without requiring
hardfail)
- wait a few months (at least long enough for some credential rollover
to happen, to ensure that this happens smoothly)
- review any received reports in that window
- if problems, fix problems and start over
- if no problems, consider turning on hard-fail
I worry that TLSA alone isn't expressive enough to support that rollout,
and that jumping straight to a hard-fail mechanism will scare people
from deploying. Maybe those fears are misplaced, though.
--dkg
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
