Re: [dns-privacy] bootstrapping NS names, was re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

2020-06-10 Thread John R Levine
On Wed, 10 Jun 2020, Brian Dickson wrote: The principle is easy. What's hard is the Provisioning Crudware(TM) that will have to be updated to handle TLSA glue. You might see this as a dealbreaker, with the alternative being to abuse DS or some other record that we hope the Crudware already

Re: [dns-privacy] bootstrapping NS names, was re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

2020-06-10 Thread Brian Dickson
On Wed, Jun 10, 2020 at 12:29 PM John Levine wrote: > In article eac7d...@mail.gmail.com> you write: > >That leaks information to an attacker ONLY if the attacker has > successfully > >caused the resolver to get the wrong NS name at the first step. > > > >There is a method for preventing that:

Re: [dns-privacy] bootstrapping NS names, was re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

2020-06-10 Thread John Levine
In article you write: >That leaks information to an attacker ONLY if the attacker has successfully >caused the resolver to get the wrong NS name at the first step. > >There is a method for preventing that: if the delegating name server (e.g. >TLD) supports DNS-over-TLS-to-Authority (DoTA), and

Re: [dns-privacy] NS names, was re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

2020-06-10 Thread Brian Dickson
On Wed, Jun 10, 2020 at 8:33 AM John R Levine wrote: > >> That sounds quite painful for servers that serve hundreds or > >> thousands of zones. > > I think this will work for NS with names in the zone. Still scratching my > head about NS in other zones. > So, this seems to be failing

Re: [dns-privacy] NS names, was re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

2020-06-10 Thread John R Levine
That sounds quite painful for servers that serve hundreds or thousands of zones. I think this will work for NS with names in the zone. Still scratching my head about NS in other zones. On a referral, the parent server sends TLSA records as glue along with the NS and DS in the

Re: [dns-privacy] NS names, was re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

2020-06-10 Thread Bill Woodcock
> On Jun 10, 2020, at 4:50 PM, Shumon Huque wrote: >> How does this differ from the two already-competing “oblivious DNS” >> proposals? > I haven't followed recently. Has a draft been submitted to DPRIVE? Not to the best of my knowledge, but I am also not following closely. It seems to be

Re: [dns-privacy] NS names, was re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

2020-06-10 Thread Shumon Huque
On Wed, Jun 10, 2020 at 10:17 AM Bill Woodcock wrote: > > >>> > The more I think about all the privacy leaks that have to be plugged > at the DNS and application layers, Tor increasingly looks better as a > general purpose solution (either as a network to funnel DNS messages > through, or even

Re: [dns-privacy] NS names, was re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

2020-06-10 Thread Bill Woodcock
>>> > The more I think about all the privacy leaks that have to be plugged at >>> > the DNS and application layers, Tor increasingly looks better as a >>> > general purpose solution (either as a network to funnel DNS messages >>> > through, or even better, having zone operators locate

Re: [dns-privacy] NS names, was re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

2020-06-10 Thread Shumon Huque
On Wed, Jun 10, 2020 at 9:37 AM Paul Wouters wrote: > > On Jun 10, 2020, at 07:55, Shumon Huque wrote: > > > > > > > > The more I think about all the privacy leaks that have to be plugged at > > the DNS and application layers, Tor increasingly looks better as a > > general purpose solution

Re: [dns-privacy] NS names, was re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

2020-06-10 Thread Paul Wouters
On Jun 10, 2020, at 07:55, Shumon Huque wrote: > >  > > The more I think about all the privacy leaks that have to be plugged at > the DNS and application layers, Tor increasingly looks better as a > general purpose solution (either as a network to funnel DNS messages > through, or even

Re: [dns-privacy] NS names, was re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

2020-06-10 Thread Shumon Huque
On Tue, Jun 9, 2020 at 11:43 PM Christian Huitema wrote > There are two tests that matter: first, verify that the NS record is > genuine and that the designated server is indeed the server chosen by the > target domain; two, verify that the TLS connection terminates at the > specified server. It

Re: [dns-privacy] re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

2020-06-10 Thread Peter van Dijk
On Tue, 2020-06-09 at 16:33 -0400, Paul Wouters wrote: > On Tue, 9 Jun 2020, Robin Geuze wrote: > > > So lets start at the beginning, why do we want to encrypt the communication > > between then resolvers and the authoritatives in the first place. There are > > two main reasons for encrypting