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 -> TLS Handshake -> DNS Request/Reply -> TLS
Close -> TCP Close.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?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),
Islamabadhttps://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]] On Behalf Of Paul
> Hoffman
> Sent: Friday, October 23, 2015 8:01 PM
> To: Simon Josefsson
> Cc: [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]> 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
discusses both TLS and DTLS profile for providing DNS privacy.
-Tiru
>
> --Paul Hoffman
_______________________________________________
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
