Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

On Thu, Jan 9, 2020 at 10:03 AM Sara Dickinson wrote: > > > On 7 Jan 2020, at 22:47, Eric Rescorla wrote: > > > > On Tue, Jan 7, 2020 at 10:37 AM Sara Dickinson wrote: > >> >> >> On 19 Dec 2019, at 02:09, Eric Rescorla wrote: >> >> >> >> On Wed, Dec 18, 2019 at 7:06 AM Sara Dickinson wrote:

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

On Fri, Jan 10, 2020, at 05:03, Sara Dickinson wrote: > “As with many other protocols issues around centralisation also arise > with DNS. The picture is fluid with several competing factors > contributing which can also vary by geographic region. These include: > * ISP outsourcing, including to

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

> On 7 Jan 2020, at 22:47, Eric Rescorla wrote: > > > > On Tue, Jan 7, 2020 at 10:37 AM Sara Dickinson > wrote: > > >> On 19 Dec 2019, at 02:09, Eric Rescorla > > wrote: >> >> >> >> On Wed, Dec 18, 2019 at 7:06 AM Sara Dickinson >

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

On Tue, Jan 07, 2020 at 06:37:38PM +, Sara Dickinson wrote a message of 278 lines which said: > There is currently no standardized discovery mechanism for DoH and > Strict DoT servers so applications that might want to dynamically > discover such encrypted services are not able to. At the

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03

On Tue, Jan 07, 2020 at 06:39:18PM +, Sara Dickinson wrote a message of 194 lines which said: > > on the basis that it assumes that these optimizations are deployed > > without regard to privacy. May be just an informative reference to RFC 7231, specially section 9.7, would please

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03

On Wed, Jan 8, 2020 at 6:06 PM Martin Thomson wrote: > On Wed, Jan 8, 2020, at 23:51, Eric Rescorla wrote: > > On Tue, Jan 7, 2020 at 8:28 PM Rob Sayre wrote: > > > Couldn't servers give out unique URI templates? > > > > DoH doesn't specify how the clients get the templates. At least for a > >

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03

On Wed, Jan 8, 2020, at 23:51, Eric Rescorla wrote: > On Tue, Jan 7, 2020 at 8:28 PM Rob Sayre wrote: > > Couldn't servers give out unique URI templates? > > DoH doesn't specify how the clients get the templates. At least for a > Firefox-style TRR program, what you describe can't happen because

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03

On Tue, Jan 7, 2020 at 8:28 PM Rob Sayre wrote: > On Tue, Jan 7, 2020 at 8:15 PM Martin Thomson wrote: > >> But it is true that HTTP has grown a number (many) of similar features. >> You could - as this document strong implies - suggest that multitude of >> options makes it a risky proposition

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

Il 08/01/2020 09:10 Christian Huitema ha scritto: Centralization manifests itself in many ways. EKR is correct that big ISP do get a huge part of the traffic -- last time I checked, there was at least one ISP in China and another in India that served

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

> On 8 Jan 2020, at 08:10, Christian Huitema wrote: > > > > On 1/7/2020 12:47 PM, Eric Rescorla wrote: >> To address the more general problem I suggest: >> >> “Should the trend away from using ISP managed resolvers to using a small set >> of large public resolvers continue, then an

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

On 1/7/2020 12:47 PM, Eric Rescorla wrote: > > To address the more general problem I suggest: > > “Should the trend away from using ISP managed resolvers to using a > small set of large public resolvers continue, then an increased > proportion of the global DNS resolution traffic

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03

On Tue, Jan 7, 2020 at 8:15 PM Martin Thomson wrote: > But it is true that HTTP has grown a number (many) of similar features. > You could - as this document strong implies - suggest that multitude of > options makes it a risky proposition to use HTTP because of the surprising > ways in which

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03

This thread is starting to get hard for me to follow. Apologies if something goes missing. On Wed, Jan 8, 2020, at 05:39, Sara Dickinson wrote: > Propose using text suggest by Ekr here: "The privacy risks associated > with other protocols that make use of DNS information are not > considered

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

On Tue, Jan 7, 2020 at 10:37 AM Sara Dickinson wrote: > > > On 19 Dec 2019, at 02:09, Eric Rescorla wrote: > > > > On Wed, Dec 18, 2019 at 7:06 AM Sara Dickinson wrote: > >> >> >> > On 2 Dec 2019, at 00:00, Martin Thomson wrote: >> > > > > >> Suggest replacing the last 4 paragraphs of this

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03

> On 2 Jan 2020, at 01:03, Martin Thomson wrote: > > On Thu, Dec 19, 2019, at 02:06, Sara Dickinson wrote: >> To try to separate out the issue with the text in Section 3.5.1.1 I’ll >> respond to the comments on that in a separate thread and try to address >> the other issues in this email.

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

> On 19 Dec 2019, at 04:05, Rob Sayre wrote: > > > > On Wed, Dec 18, 2019 at 6:10 PM Eric Rescorla > wrote: > > “It has been pointed out that should the trend towards using large public > resolvers increase, an increased centralisation of DNS resolution services >

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

> On 19 Dec 2019, at 02:09, Eric Rescorla wrote: > > > > On Wed, Dec 18, 2019 at 7:06 AM Sara Dickinson > wrote: > > > > On 2 Dec 2019, at 00:00, Martin Thomson > > wrote: > > Suggest replacing the last 4 paragraphs of this section

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03

On Thu, Dec 19, 2019, at 02:06, Sara Dickinson wrote: > To try to separate out the issue with the text in Section 3.5.1.1 I’ll > respond to the comments on that in a separate thread and try to address > the other issues in this email. Ack. Ekr's answer will suffice for mine there. > > BTW,

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

On Wed, Dec 18, 2019 at 6:10 PM Eric Rescorla wrote: > >> “It has been pointed out that should the trend towards using large public >> resolvers increase, an increased centralisation of DNS resolution services >> will result. >> > > Well, it's been pointed out, but it's not at all clear that

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

On Wed, Dec 18, 2019 at 7:06 AM Sara Dickinson wrote: > > > > On 2 Dec 2019, at 00:00, Martin Thomson wrote: > > > > Prompted by my surprise at seeing Brian Trammell's mention of a > '[firefox]' reference in this document, I reviewed the contents of this > draft more closely. > > > > Summary >

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

> On 2 Dec 2019, at 00:00, Martin Thomson wrote: > > Prompted by my surprise at seeing Brian Trammell's mention of a '[firefox]' > reference in this document, I reviewed the contents of this draft more > closely. > > Summary > > I found a number of issues with the additions in this -bis

Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03

> On 2 Dec 2019, at 00:00, Martin Thomson wrote: > > Prompted by my surprise at seeing Brian Trammell's mention of a '[firefox]' > reference in this document, I reviewed the contents of this draft more > closely. > > Summary > > I found a number of issues with the additions in this -bis

[dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03

Prompted by my surprise at seeing Brian Trammell's mention of a '[firefox]' reference in this document, I reviewed the contents of this draft more closely. Summary I found a number of issues with the additions in this -bis document. Of particular concern is Section 3.5.1 (formerly Section