On Fri 2021-12-10 20:11:59 -0500, Robert Evans wrote: > This should ideally be replaced with "resolvers discovering TLS support > solely via unilateral probing MUST NOT perform ANY authentication or > validation whatsoever on the TLS certificate(s) presented by the > authoritative name server".
This might be a bit excessive -- surely there's no harm in a recursive
resolver trying to validate a given name and then throwing that
information away. Or, validating a name and sending a report to the
server (via some as-yet-undefined mechanism) if the validation fails.
What the opportunistic unilateral-probing recursive resolver MUST NOT do
is abort the handshake or otherwise delay, penalize, or constrain the
connection due to server authentication failure, right?
> As an example, certificate pinning by resolvers would cause TLS certificate
> auto-rotation to break. Validation might also break "automatic
> opportunistic TLS" where the server self-provisions a self-signed cert for
> its lifetime and throws it away on restart. When used on an anycast
> network, those servers would all have valid certs but every connection
> might present unrelated certs. If the resolver tries to be clever, adding
> more servers might break everything.
I agree that this would be problematic -- we don't want to encourage
that kind of fragility.
--dkg
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
