Yup and it looks dnscrypt could be used to launch DDOS attack on victim. -Tiru
> -----Original Message----- > From: dns-privacy [mailto:dns-privacy-boun...@ietf.org] On Behalf Of Paul > Wouters > Sent: Monday, April 27, 2015 7:35 PM > To: Watson Ladd > Cc: dns-privacy@ietf.org; Dan Wing (dwing) > Subject: Re: [dns-privacy] DPRIVE over UDP or TCP > > On Sun, 26 Apr 2015, Watson Ladd wrote: > > > If what we end up with is doing the same crypto operations as > > DNSCrypt, but with the extra complexity of managing connections > > (opening, closing, resuming, etc), what is the advantage? > > I've said this before...... > > My understanding of dnscrypt is that it is just a static preconfigured VPN > using some custom way of sending an X.509 certificate over TXT records, > using some adhoc headers thrown in. The closest thing to a specification I > can find is: > > https://github.com/jedisct1/dnscrypt-proxy/blob/master/TECHNOTES > > which states: > > One or more TXT records are returned, each containing a signed > certificate. > The provider public key is only used to verify a certificate, never for > authenticating/encrypting queries. > Certificates have the following header: > - 4 byte magic header DNSC > - 2 byte major version > - 2 byte minor version > Followed by signed content (the signature adds 512 bits to the > payload): > - server 256-bit public key > - 8 byte magic header to use for queries using this specific key > - 4 byte serial number > - 4 + 4 byte validity period (two timestamps) > > I'm unsure why we need a new way to authenticate that shoves certs in > adhoc TXT recods. Why not use TLS on some other port, even if we then later > to DNS on port 53 with whatever dnscrypt magic? If this is a really cool way > of doing things (which I don't think it is) than we should not be using TXT > records but a new RRTYPE. > > It also seems rather hardcoded with odd values, very un-agile and centered > on The One True Encryption Protocol. > > And dnscrypt is then topped of with: > > This is the current structure of the second version of the protocol. > Don't assume anything about its length, it is very likely to change > after a version bump. > > So the designers have no idea if they are going to completely rewrite this. > Does not sound like it is anywhere near ready for standardization. > > Which is why dnscrypt is not a real contender and we should steer this > discussion back to the 3 considered proposals. > > >>> We know that approaches similar to DNSCrypt don't have these > problems. > > So this seems to be a statement that cannot be translated into technical > terms. What is this "similar approach" that is missing from the other > proposals that supposedly makes dnscrypt so much different and better? > > In fact, I see nothing that makes dnscrypt any better that using a > preconfigured X.509 based IPsec VPN possibly limited to udp/tcp 53 traffic > selectors. > > dnscrypt might be a nice hack to solve a short term issue in light of hostile > and/or never-upgraded networks with some success of bypassing the > network administrator restrictions. But it is not an architecture for future > deployment. > > Paul > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
