One of the concerns raised at IETF 112 about draft-dkgjsal-dprive-unilateral probing was that unilateral probing by recrusive resolvers might "poison the well" and discourage authoritative servers from deploying encrypted transport.
For example, in jabber, Erik Nygren commented: "TOFU has a big "poison the well" risk here that will prevent operators from enabling." https://jabber.ietf.org/jabber/logs/dprive/2021-11-11.html#13:07:33.595176 ("TOFU" means "Trust on First Use") I think this is a legitimate concern: one of the goals of the draft is to describe how to probe in a way that *doesn't* discourage adoption. Would folks who have this concern (maybe including Erik, if you're reading!) take a look at the draft and identify any specific behavior that you think could be problematic? I don't think the behavior that Joey and I have specified in unilateral-probing does TOFU, since it's entirely unconcerned with authentication. So there is no "trust on first use" with regards to choice of server authentication credentials from this perspective. If an initial attempt at encrypted transport fails, there will be no penalty, because the cleartext query is ("happy eyeballs"-style) already in flight. If an authoritative server never offers an encrypted transport, each recursive resolver client will check its status at most once a day (see the `damping` parameter), and will accept a "port closed" message as a failure, so it's not going to increase costs for cleartext-only authoritatives in any significant way. This should also reduce concerns about runaway retries consuming excessive resources. And, if an authoritative that has previously offered encrypted transport stops offering it, there will be at most a one-time very short delay (a few seconds, see the `timeout` parameter) for each recursive resolver that had expected encrypted transport, before it falls back to cleartext. So i think the probing described here shouldn't scare anyone off from deploying at the authoritative. Is this analysis missing something? --dkg
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
