On Sat, Feb 15, 2014 at 4:24 PM, Paul Vixie <[email protected]> wrote: > > > Watson Ladd wrote: > > On Sat, Feb 15, 2014 at 10:08 AM, Paul Vixie <[email protected]> wrote: > > ... The answer is that Curve25519 passes all > requirements on elliptic curves: it is safe against all known attacks. > > > SSH1 was safe against all known attacks, until the first one. turns out > "integer underflow" was not previously a known attack. let's all learn some > caution about what we define as "safety", lest the gods strike us down for > our temerity.
Fine: Curve25519 is just as dangerous as every other curve that passes the current requirements. > > > Thirdly, this proposal ignores entirely how to validate the server > over the TLS connection. Does it need a certificate? Who should be > allowed to sign it? How should it be validated? DNSSEC provides a PKI, > and this proposal provides another one. Their interactions will not be > fun. > > see above; i don't think this proposal offers or intends to offer a PKI, > merely a hop-by-hop confidentiality option. DNSSEC will still be required. > > If we don't have authentication, we don't have confidentiality: MITM > is possible. > > > 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? > > > Secondly, "hop-by-hop" means what for DNS? If all this secures is the > connection between a client and the full resolver, then this doesn't > protect the confidentiality of anyone doing a DNSSEC query, as > resolvers cannot return the data required to validate DNSSEC. > > > all arguments of the form "DANE can't be deployed because of middleboxes" > beg the answer "we will have to send JSON over HTTPS using a RESTful query > to protect the last mile , see bortzmeyer's draft on that subject." So I was wrong: you need a validating stub resolver, which can still use a separate recursive resolver to find things, so caches aren't as bad as I thought they were. > > > It also > doesn't protect against the cache recording what is being looked up. > > > 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. > > > dnscurve was offered to the ietf community but it didn't stick for > reasons unrelated to this newer proposal. i don't see any sense in > comparing their installed bases. > > That reason was caches everywhere are very useful to reduce load on > DNS servers, > > > well, no. caches everywhere are very useful to reduce latency for clients. > authority servers today must be so massively overprovisioned for DDoS > reasons that any multiple of normal load even if no caches existed anywhere > would be pretty much line noise. > > > vixie Sincerely, Watson Ladd _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
