On Sat, Feb 15, 2014 at 7:34 PM, Paul Vixie <[email protected]> wrote: > > > Watson Ladd wrote: > > On Sat, Feb 15, 2014 at 4:24 PM, Paul Vixie <[email protected]> wrote: > > the MiTM problem is due to X.509 not TLS per se. DANE stops MiTM for TLS. my > comfort level with DTLS, or STARTTLS-over-EDNS, or TLS or SSL, is the same: > low with X.509 since most nation-state actors and many criminal actors can > feed any endpoint a certificate they will believe no matter what the name > is; high once we pitch X.509 into the ash bin of history and get DANE > running everywhere. > > Unfortunately this isn't in the draft. Furthermore, DANE only links a > server to a domain name: it doesn't let me know that the DNS resolver > with the name moescoffee.com is not the resolver for the coffee shop I > am in. DANE could protect nameservers, but we already put the keys of > nameservers into DNS, and it's fairly easy to guess what query I am > sending to dns.ewr1.nytimes.com, so encrypting the query to that > server doesn't gain much. How does DANE work when we are dealing with > devices without domain names, like the router in Moe's Coffee? > > > i expect i'm about to defer to paul hoffman as to the details of DANE. my > coarse-grained understanding is that the distinguished name will come from > the first term of the URI, which means that the key fingerprint will mostly > be in normal ("forward") space but could be in in-addr ("reverse") space. > it's a straightforward mapping problem, if moe's coffee's router is at > 192.168.1.1 for you, then moe's router's key fingerprint had better be at > 1.1.168.192.in-addr.arpa for you. exactly how you bootstrap localized > split-view DNS when NAT'd is a hard but tractible problem. let's assume that > moe's router's IP is 2001:200:dff:fff1:216:3eff:fe4b:651c and that his > router's key fingerprint is at > c.1.5.6.b.4.e.f.f.f.e.3.6.1.2.0.1.f.f.f.f.f.d.0.0.0.2.0.1.0.0.2.ip6.arpa. > not that i know why you want to contact moe's router but that's the question > you asked.
Because I'm in the coffee shop, connected to their wifi. I'm not entirely sure of the semantics of arpa based key lookups, but I'll take your word for it that it works correctly. > > >> well, yes. if someone wants to look stuff up in DNS without middleboxes >> knowing what they looked up, they have to use a VPN. > > So what does this draft change in that regard? I'm not really seeing > the gains to privacy that > were promised, except maybe against other evesdroppers on the same > segment who aren't using > active attacks. > > > TLS gets you privacy if you take X.509 out of the circuit. this proposal is > about adding TLD to DNS. other proposals have been made having the goal of > getting the world out of X.509 hell. it's the two proposals together that > give us privacy. > > vixie The crypto seems fine: you get the address you were looking for with only the cache knowing about it. And then you turn around and connect to the address given you by DNS. Onion-routing is the only solution to this problem, but in that case you can onion-route the DNS lookups. Sincerely, Watson Ladd _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
