On 26-Oct-2015 07:28 am, Muhammad Yousaf <[email protected]> wrote: > Hi all, > I am new to this list, infact read the document for the first time. So, don't > know whether my comments will make any sense or not. > My first feeling is that this document is proposing too much security > overhead in the name of privacy protection. > TCP Handshake
TCP FastOpen (RFC7413), which would contain the TCP ClientHello > -> TLS Handshake Which would use TLS session resumption w/o server-side state (RFC5077), and TLS FalseStart (draft-ietf-tls-falsestart). > -> DNS Request/Reply -> TLS Close -> TCP Close. The TLS session and TCP connection don't need to be closed right away. If left open, subsequent queries have nearly the same overhead as today's un-encrypted queries, and as long as the network is stable (NAT, firewall, path), DNSoTLS and DNSoDTLS are very similar in their operation. > Although draft discussed the overhead, however, only discussion can't resolve > the issue. > Draft also discussed the long term persistant connections and associated > security issues with this approach. Again discussion only is not the solution. > Draft also discussed the queued requests and its issue. Again no satisfactory > solution. > Also, it is not clear that why we need to encrypt the traffic between > recursive server and the authoritative server. What is the privacy issue > there? The risk is a victim querying a unique (or nearly unique) resource record), such as ejkfjuiuerekfjekfjekfjekjfejqkjkejqkj.example.com <http://ejkfjuiuerekfjekfjekfjekjfejqkjkejqkj.example.com/> (which might be completely unique to that particular user) or such as "kitten-pictures.blogspot.com <http://i-love-kittens.blogspot.com/>" (where kitten pictures are deemed subversive or are illegal). Imagine that unique query combined with draft-ietf-dnsop-edns-client-subnet. -d > If community is not in a hurry, then in my humble opinion, standard body > should look for more efficient and well thought off solution may be out of > TLS. > I can volunteer for any such activity. > > Best Regards, > Dr. Muhammad Yousaf, > Assistant Professor, Faculty of Computing, > Riphah International University (RIU), Islamabad > https://sites.google.com/site/muhyousaf/ > <https://sites.google.com/site/muhyousaf/> > > > > On Sunday, October 25, 2015 9:23 PM, Tirumaleswar Reddy (tireddy) > <[email protected]> wrote: > > > > -----Original Message----- > > From: dns-privacy [mailto:[email protected] > > <mailto:[email protected]>] On Behalf Of Paul > > Hoffman > > Sent: Friday, October 23, 2015 8:01 PM > > To: Simon Josefsson > > Cc: [email protected] <mailto:[email protected]> > > Subject: Re: [dns-privacy] Start of WGLC for > > draft-ietf-dprive-dns-over-tls-01 > > > > On 10/23/15, 1:35 PM, "Simon Josefsson" <[email protected] > > <mailto:[email protected]>> wrote: > > > > >Hi. I believe the document is in relatively good shape. I have one > > >high level concern, and one concern with the document itself that is > > >related to the higher-level concern: > > > > > >1) I believe it would be a mistake to publish this without > > >synchronizing the TLS-related aspects of DNS-over-TLS and > > >DNS-over-DTLS. The documents solve roughly the same problem, with > > >rougly the same technology. One important difference is how they > > >approach authentication of the peer in TLS. Given the similarities of > > >the protocols and solutions, this seems like a recipe for > > >implementation frustration. An implementer would prefer to implement > > >DNS-over-TLS/DTLS as similar as possible. Having different X.509 (etc) > > >certificate verification code paths depending on whether TLS or DTLS is > > >used appears bad to me. > > > > > >2) On TLS verification, this document should reference RFC 6125 and > > >describe how naming information should be compared with the locally > > >known data with what is being presented by the server. See > > >draft-ietf-dprive-dnsodtls for one way (not necessarily the best one or > > >the most readable or complete way) of doing this. > > > > > >If merging DNS-over-TLS and DNS-over-DTLS is not an option, another > > >possibility is that TLS-related aspects are deferred from both > > >documents to another third new document that describe how to perform > > >TLS credential verification for DNS-over-(D)TLS in a generalized way. > > >Then there would be harmony in the TLS-related aspects, and the > > >respective document can focus on the DNS-related aspects. If document > > >editor cycles is limiting factor, I would volunteer to help write this. > > > > Fully agree on all counts. If the WG wants to move both -TLS and -DTLS to > > the > > IETF, it makes no sense at all to have them have different crypto > > properties. I > > don't care if the answer is "harmonize each before finishing" or "harmonize > > them by reference to a third document". > > https://tools.ietf.org/html/draft-wing-dprive-profile-and-msg-flows-00 > <https://tools.ietf.org/html/draft-wing-dprive-profile-and-msg-flows-00>discusses > both TLS and DTLS profile for providing DNS privacy. > > -Tiru > > > > > --Paul Hoffman > > _______________________________________________ > dns-privacy mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/dns-privacy > <https://www.ietf.org/mailman/listinfo/dns-privacy> > > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
