On Sat, Feb 15, 2014 at 10:08 AM, Paul Vixie <[email protected]> wrote: > > > Watson Ladd wrote: >> Dear all, >> This proposal has multiple shortcomings compared to DNSCurve. >> >> First off, it says that the rationale for TLS over DNSCurve is simply >> to "take advantage of TLS". I would respectfully submit that DJB can >> do a better job than the TLS committee, and did. Merely adding bolts >> and nuts onto a design is not improving it. > > has mr. bernstein's Curve25519 (see > http://en.wikipedia.org/wiki/Curve25519) been explicitly validated by > other crypto experts? last i knew he was the only one claiming it was > correct and strong enough for production use. this matters, because no > one person ought to be trusted to get something like this right sans > review. mr. bernstein's competence isn't being questioned, it's just the > "second set of eyes" requirement for technology at scale. i'm speaking > as an x.509-hater, which means, i tend to agree with what you said about > committees.
Do you mean the curve or the implementation? The answer is that Curve25519 passes all requirements on elliptic curves: it is safe against all known attacks. You can validate this in a few minutes with PARI. The implementation has been validated as well, including a test against independent implementation I did a few years ago. As for review, considerable effort exists on solving DLP on curves. It is a very thoroughly studied problem. > > as a bolter-onner of many of dns's nuts including EDNS, i'm ready to > quibble with anyone who says DNS has not been improved by the post-1987 > work that's been done to it. i won't claim it's gotten prettier, but > that's not the only metric for "improvement". > >> Secondly, this proposal only works on TCP. This imposes latency and >> state requirements that most people would rather avoid. The use of >> keepalive only addresses computational burden, not state burden, and >> with the DH speed records we have today unnecessary. > > my understanding is that this is a hop-by-hop cover protocol for adding > confidentiality when needed, and that something like dnssec will still > be needed for end-to-end content authenticity. in that sense the tcp > requirement isn't itself burdensome, though i will certainly recommend a > block-cipher mode so that udp can also be supported. this is not > something we can fix with DTLS or SCTP because of the all-pervasive > "middlebox problem". even getting EDNS options through has proved > difficult, a completely new transport is unthinkable. > >> 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. 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. It also doesn't protect against the cache recording what is being looked up. All it protects against is someone eavesdropping on the cache, and because we aren't putting in certificate validation requirements, it doesn't even protect against that. > >> Fourthly, there is substantial operational knowledge and deployed, >> working, code implementing DNSCurve. This does not hold for this >> proposal. > > 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, and the dnscurve security model couldn't work with them effectively. Perhaps we should work on PIR protocols to secure the retrieval of information from caches: putting data into the cache would still be an issue, but we could hide the number and names of people who want the information that gets retrieved. > >> Sincerely, >> Watson Ladd > > warmly, > > vixie Sincerely, Watson Ladd _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
