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

"Mankin, Allison" writes: > My two cents is that the authentication profile for TLS and DTLS > should not be the same as a draft with flows. > > I reviewed the flows draft before it was submitted (and thank the > authors for responding to initial comments). Unsurprisingly,

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

Warren Kumari writes: > Dear DPRIVE WG, > > The authors of draft-ietf-dprive-dns-over-tls-01 have indicated that > they believe that the document is ready, and have asked for Working > Group Last Call. Hi. I believe the document is in relatively good shape. I have one high

Re: [dns-privacy] New DPRIVE evaluation document

Hello. This is a useful document, thank you for working on it.I believe there is one fundamental aspect that you may want to consider and address. When I read this document it sometimes give me the impression that the only interesting attack to protect against are passive attacks. In

Re: [dns-privacy] I-D Action: draft-ietf-dprive-dns-over-tls-00.txt

"Wessels, Duane" writes: > The former draft described two approaches to establishing a > DNS-over-TLS session: upgrade-based (aka STARTTLS for DNS) and > port-based. In this new version we have removed the upgrade-based > approach and describe only the use of a well-known

Re: [dns-privacy] Call For Adoption: draft-wing-dprive-dnsodtls

Tim Wicinski tjw.i...@gmail.com writes: The draft is available here: https://datatracker.ietf.org/doc/draft-wing-dprive-dnsodtls/ Please review this draft to see if you think it is suitable for adoption by , and comments to the list, clearly stating your view. Please also indicate if you

Re: [dns-privacy] I-D Action: draft-ietf-dprive-start-tls-for-dns-00.txt

Phillip Hallam-Baker i...@hallambaker.com writes: Google is currently working on HTTP over UDP to shave a second of page load times. This group is working is proposing to move the most latency critical interaction from UDP to TLS. Some people here pointed out that the initial goal is

Re: [dns-privacy] How many mechanisms in draft-ietf-dprive-start-tls-for-dns?

Christian Huitema huit...@huitema.net writes: On any other topic I would agree. Breaking DNS should be one of the things to worry about. Maybe we should make the distinction between stub resolver and iterative resolver part of the architecture. This would be very much the same split as

Re: [dns-privacy] How many mechanisms in draft-ietf-dprive-start-tls-for-dns?

Paul Hoffman paul.hoff...@vpnc.org writes: That approach is what dual-stack IPv4+IPv6 applications did before people realized defining fails is non-trivial and came up with the happy eyeballs approach to let the quickest path win, and not bother waiting for the fail to be determined. And if

Re: [dns-privacy] I-D Action: draft-ietf-dprive-start-tls-for-dns-00.txt

Daniel Kahn Gillmor d...@fifthhorseman.net writes: On Tue 2015-05-12 14:40:12 -0400, Simon Josefsson wrote: What I'm basically wondering, and advocating, is if perhaps one method would be sufficient. This would reduce complexity on the protocol and implementation level. I agree

Re: [dns-privacy] I-D Action: draft-ietf-dprive-start-tls-for-dns-00.txt

Paul Hoffman paul.hoff...@vpnc.org writes: Having two parallel mechanisms for a latency-sensitive protocol leads to the necessity of doing a happy eyeballs approach in implementation to decrease latency. That's only true of the specifications don't say what to do first. However,

Re: [dns-privacy] I-D Action: draft-ietf-dprive-start-tls-for-dns-00.txt

Hi. This document define essentially two mechanisms: port-based DNS-over-TLS AND upgrade-based DNS-over-TLS. I may have missed earlier discussions about this design choice. However I want to understand why you want/need this complexity, to make sure there really was a good motivation behind

Re: [dns-privacy] Call for Adoptions on the 3 documents.

Ilari Liusvaara ilari.liusva...@elisanet.fi writes: I'll update my position on WG adoption a bit: I support adopting DNS-over-TLS but urges the WG to adopt DNS-over-DTLS at the same time, and make consistency between them a requirement. Having both with different TLS-related security

Re: [dns-privacy] Last Call: draft-ietf-dprive-problem-statement-04.txt (DNS privacy considerations) to Informational RFC

This is a good document, that I recommend people to read: https://tools.ietf.org/html/draft-ietf-dprive-problem-statement One risk concerning DNS privacy that I couldn't see discussed is one that may be too obvious so that it was forgotten. That is the risk of someone on the Internet actively

Re: [dns-privacy] Call for Adoptions on the 3 documents.

I agree that DNSCurve is the best solution. I didn't say that. I believe DNSCurve and DNS-over-(D)TLS are somewhat different, and which is best depends on what you appreciate. DNS-over-(D)TLS is to me clearly the best answer for stub resolvers talking to an iterative resolver, which appears to