Ted Lemon wrote: ....
If you are trusting a "pre-shared key," why not just pre-share the DoT server information? ...
because my preferred DoT server may not work inside someone else's network. ....
The reason it's not drama-free is because you can't just hand-wave the threat model. What you just said is a fine way for you, Paul Vixie, a knowledgeable user, to configure your device, but I can't explain this threat model to a typical end user, and they have no basis for deciding what they should do. You mention the GFWoC, and that's certainly a use case we need to consider, but we also need to consider the use case of the malicious coffee shop network that wants to harvest your passwords.
i thought we'd spent 19 years on DNSSEC to deal with that threat, along with DANE and TLS 1.3. if it's still an unsolved problem, then i dare say that we won't be fixing it by telling people not to use RDNS stub servers that are recommended to them by their address provider via DHCP.
I don't know if you have friends who've been taken by this scam, but I have, and it cost them a /lot./ So how does my host tell the GFWoC from the malicious coffee shop server? Assume that it can't ask me to figure it out—it has to follow some decision heuristic that is programmed in at the factory.
when i go to defcon, my software updates all fail, because signatures are wrong. luckily, the vendors of my software understand this problem. even my bios vendor signs their updates in a way that the recipient can tell there's a forgery. i would _not_ expect to be able to mitigate any of those risks by changing who i received my DNS responses from.
-- P Vixie _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
