On Thu, Apr 23, 2015 at 6:46 AM, Warren Kumari <[email protected]> wrote: > On Wed, Apr 22, 2015 at 8:43 PM, Watson Ladd <[email protected]> wrote: >> I agree that DNSCurve is the best solution. > > ... which a: was not one of the options, b: is recursive to auth and > c: has not been written up in a draft and brought to the WG. > > Please see the threads from October 2014 on DNSCurve (and DNSCrypt), > which included a bunch of information and also: > "Ok, so how about we say that it isn't a solution that we are currently > considering, but if folk fully document dnscurve / dnscrypt in a > draft, and bring it to the IETF / DPRIVE we will might consider it > (and, obviously if it becomes a WG item, change it to meet the our > requirements...) > "
Looking through the archives I see that in October the DNSCrypt people promised to write and upload a draft. That never happened, unfortunately. > > >> Many of the proponents of >> TLS based solution haven't adequately considered how this affects >> anycast, DOS resistance, etc. Confidential-DNS can only be fixed by >> essentially becoming DNSCurve. >> >> It's clear that deployed, working solutions need to be adopted. When >> people say it's easy to implement DNS-over-TCP/TLS, and haven't, I >> think that's a warning sign. > > Ok, so I'll assume you haven't been following along then. > > Please see: > From the Dallas meeting: 'draft-hzhwm-dprive-start-tls-for-dns: DNS > over TLS" - https://www.ietf.org/proceedings/92/slides/slides-92-dprive-0.pdf > - Slide 6 > > From the Hawaii meeting: 'DNS over TCP and TLS > draft-hzhwm-dprive-start-tls-for-dns-00' - > http://www.ietf.org/proceedings/91/slides/slides-91-dprive-5.pdf - > Basically all of it, but mainly slides 21, 22, 23. Page 27 had a demo > of drill talking to unbound... I agree: we do have an implementation. Thanks for correcting me. > > Also, see http://www.isi.edu/ant/software/tdns/index.html, including digit. > > $ tar -xvzf digit-1.4.tar.gz && cd digit && autoreconf --install && > ./configure --without-gnutls && make > $ echo -e 'www.google.com\nwww.yahoo.com\nwww.ietf.org' > names.txt > # StartTLS > $ ./digit -V -r 185.49.141.38 -f ./names.txt -p 53 -t ssl > # Direct over SSL. > $ ./digit -V -r 185.49.141.38 -f ./names.txt -p 1021 -t ssl -e > > The 185.49.141.38 (and 2a04:b900:0:100::38) test / demo server is > running on the getdns jail, and is run by the getdns team; the getdns > developers can all access and manage it (it was originally set up for > the Bits-n-Bites demo). NLnet Labs is a collaborator > in the getdns project, and very kindly provides hosting. > > The digit code was written as a test / research project, and is useful > for testing -- there are other things like the tdns_cli_proxy (also on > that page) to e.g try using this like a user. > There is also the Sinodun work > (https://portal.sinodun.com/wiki/display/TDNS/DNS-over-TLS+Project+Homepage) > , including a page helpfully called "Try DNS-over-TLS"... > > > W > > > > > >> >> Sincerely, >> Watson Ladd >> >> On Wed, Apr 22, 2015 at 7:19 AM, Simon Josefsson <[email protected]> wrote: >>> I support adopting 3) draft-hzhwm-dprive-start-tls-for-dns. It may not >>> be in shipping shape, but I think it is a worthy path to pursue and can >>> be tweaked further along. In particular, I think it would be a good >>> idea to consider pushing documents for DNS-over-TCP/TLS and >>> DNS-over-UDP/DTLS at the same time, with harmonized authentication >>> language. >>> >>> Re 1 and 2, I don't understand what advantage they would give compared >>> to DNS-over-TLS, DNS-over-DTLS, or DNSCurve. I believe a strong >>> justification is necessary to motivate adoption. Frankly, I would >>> prefer DNSCurve over both 1 and 2. >>> >>> /Simon >>> >>> Warren Kumari <[email protected]> writes: >>> >>>> Hi all, >>>> >>>> So, the big day has finally arrived -- we are initiating calls for >>>> adoption on the three documents. < http://i.imgur.com/SKX3P8J.gif > >>>> >>>> For *each* of the below documents, please **clearly** state if you >>>> would like DPRIVE to adopt it, or if you think that it will be a >>>> distraction / not helpful. >>>> >>>> 1) Confidential DNS: >>>> https://datatracker.ietf.org/doc/draft-wijngaards-dnsop-confidentialdns/ >>>> >>>> 2) Private-DNS: >>>> https://datatracker.ietf.org/doc/draft-hallambaker-privatedns/ >>>> >>>> 3) TLS for DNS: Initiation and Performance Considerations: >>>> http://datatracker.ietf.org/doc/draft-hzhwm-dprive-start-tls-for-dns/ >>>> >>>> >>>> This call for adoption will be wrapping up on April 30th. >>>> At that point we will decide on one or multiple of the documents.... >>>> >>>> W >>> >>> _______________________________________________ >>> dns-privacy mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/dns-privacy >>> >> >> >> >> -- >> "Man is born free, but everywhere he is in chains". >> --Rousseau. > > > > -- > 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 -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
