On Mon, Nov 4, 2019 at 5:13 PM Eric Rescorla <[email protected]> wrote: > > > > On Mon, Nov 4, 2019 at 1:56 PM Paul Wouters <[email protected]> wrote: >> >> On Mon, 4 Nov 2019, Brian Dickson wrote: >> >> > The names of the servers (and certificate management) would be orthogonal >> > to the signaling of DoT support. I would expect the TLSA records would >> > be per-server and orthogonal to the per-zone signaling of DoT support. >> >> Again, that would be russian roulette. If I get an NS RRset with 3 >> nameservers, and only one of these has a TLSA record, what should I >> do ? >> >> 1) Pick the TLSA one >> 2) Pick a random one >> >> For 1) if this protocol is widely deployed, all clients will pick 1) so you >> just shot your redundancy in the foot. >> >> For 2) the clients get reduced privacy for no good reason, so why would a >> client do this? >> >> It is really a per-zone property, not a per-nameserver property. > > > This is a good point, and seems like an argument against all of the > opportunistic versions as well, even those with HSTS-style mechanisms. > > Suppose I look up a.example.com and get ns1.nameservers.example and > ns2.nameservers.example, and I have talked to ns1 and know it does Dot but I > don't know about ns2. What then? Or say I can't connect to ns1....
$ dig ns a.example.com ;; ANSWER SECTION: a.example.com. 42923 IN NS ns1-dot.nameservers.example. a.example.com. 42923 IN NS ns2.nameservers.example. Now, if you cannot reach ns1-dot.nameservers.example, whether you fall back to ns2.nameservers.example is a matter of client policy / paranoia. As this is an *opportunistic* / better than nothing solution I'd think that falling back makes sense. This really really isn't a replacement for a more secure, downgrade resistant solution (like Paul's), but it *is* an incrementally deployable, opportunistic convention based solution. We could do it while figuring out a better, more secure system... W > > -Ekr > >> Paul >> >> _______________________________________________ >> dns-privacy mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dns-privacy > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
