Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dns-over-tls-01

[🔓Dan Wing <[e-mail]>]

On 26-Oct-2015 07:28 am, Muhammad Yousaf <[e-mail]> 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) <[e-mail]> wrote:
> 
> 
> > -----Original Message-----
> > From: dns-privacy [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of Paul
> > Hoffman
> > Sent: Friday, October 23, 2015 8:01 PM
> > To: Simon Josefsson
> > Cc: [e-mail] <mailto:[e-mail]>
> > Subject: Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dns-over-tls-01
> > 
> > On 10/23/15, 1:35 PM, "Simon Josefsson" <[e-mail] <mailto:[e-mail]>> 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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>
> 
> 
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy