[dns-privacy] FW: New Version Notification for draft-reddy-dprive-bootstrap-dns-server-06.txt

This revision https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-06 addresses comments from the WG. Section 2 is updated to discuss scope and use cases. As a reminder, the specification discusses (1) Bootstrapping phase to securely bootstrap endpoint devices with the

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

Hi Christian, Thank you for sharing the pointer. As I understood it, the aggregation mentioned in Pawel and Oliver's study is based on an “AS name”, not AS numbers. As you know, an organization may own multiple ASNs. Mapping the 22/57 ASes to their owner would be useful, IMO. Cheers, Med De

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

On 1/8/2020 6:09 AM, mohamed.boucad...@orange.com wrote: > FWIW, slide 6 of > https://datatracker.ietf.org/meeting/104/materials/slides-104-maprg-dns-observatory-monitoring-global-dns-for-performance-and-security-pawel-foremski-and-oliver-gasser-01 > shows that very few DNS providers are handling

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] [DNSOP] DNS stamps

On Jan 9, 2020, at 6:35 AM, Stephane Bortzmeyer wrote: > Could be useful specially for secure and public resolvers, may be > worth of some IETF work? In order for this to actually be useful, two things would be required. 1. The assertions about resolver behavior (e.g., logging, etc) would have

[dns-privacy] DNS stamps

Could be useful specially for secure and public resolvers, may be worth of some IETF work? https://github.com/DNSCrypt/dnscrypt-proxy/wiki/stamps ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy

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

> On 9 Jan 2020, at 15:30, Stephane Bortzmeyer wrote: > > On Tue, Jan 07, 2020 at 02:47:02PM -0800, > Eric Rescorla wrote > a message of 310 lines which said: > >> Yeah, my point is that I don't agree with this. Right now there is a >> lot of ISP centralization and the move of some of that

Re: [dns-privacy] [DNSOP] DNS stamps

On Jan 9, 2020, at 9:21 AM, Vladimír Čunát wrote: > Depends what you'd want from the stamps. If the stamps make assertions about what service is offered, I’d want that to be verifiable. Otherwise, I can send you a stamp that makes promises I don’t intend to keep, and there’s no signature on

Re: [dns-privacy] [DNSOP] DNS stamps

On 1/9/20 6:37 PM, Ted Lemon wrote: > On Jan 9, 2020, at 9:21 AM, Vladimír Čunát > wrote: >> Depends what you'd want from the stamps. > If the stamps make assertions about what service is offered, I’d want > that to be verifiable.  [...] I'd personally have

Re: [dns-privacy] [DNSOP] DNS stamps

These stamps do contain interesting ideas, I believe. On 1/9/20 5:13 PM, Ted Lemon wrote: > In order for this to actually be useful, two things would be required. > > 1. The assertions about resolver behavior (e.g., logging, etc) would > have to be signed > [...] Depends what you'd want from the

Re: [dns-privacy] [Last-Call] last call review of draft-ietf-dprive-rfc7626-bis-03

> On 7 Jan 2020, at 22:08, Rob Sayre wrote: > > On Tue, Jan 7, 2020 at 10:35 AM Sara Dickinson > wrote: > > > > > Secondly, I found the entire section "3.5.1.5.2. DoH Specific > > Considerations" to be objectionable, and recommend removing it. It mentions > >

Re: [dns-privacy] [Last-Call] last call review of draft-ietf-dprive-rfc7626-bis-03

On Thu, Jan 9, 2020 at 10:02 AM Sara Dickinson wrote: > > > On 7 Jan 2020, at 22:08, Rob Sayre wrote: > > On Tue, Jan 7, 2020 at 10:35 AM Sara Dickinson wrote: > >> >> > >> > Secondly, I found the entire section "3.5.1.5.2. DoH Specific >> Considerations" to be objectionable, and recommend

Re: [dns-privacy] Last Call: (DNS Privacy Considerations) to Informational RFC

Hi Stephane, Brian, At 07:44 AM 09-01-2020, Stephane Bortzmeyer wrote: doh, dnssd and dprive (plus dnsop)? Yes. People (mostly at the IETF) interested by DNS privacy. When preparing RFC 7626, we saw that many IETF participants had fuzzy (and sometimes wrong) ideas about the DNS so this

Re: [dns-privacy] Last Call: (DNS Privacy Considerations) to Informational RFC

On Thu, Jan 9, 2020 at 8:49 AM S Moonesamy wrote: > > >That's a very serious misrepresentation of DoH. Counter-example: > >Google Chrome did DNS resolution with UDP, a long time ago. > > I mentioned web browser and not Google Chrome. I tested a web > browser which is not Google Chrome. The DNS

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

> On 7 Jan 2020, at 22:51, Eric Rescorla wrote: > > > > On Tue, Jan 7, 2020 at 10:38 AM Sara Dickinson > wrote: > > >> On 31 Dec 2019, at 14:45, Eric Rescorla > > wrote: >> >> >> >>> >>> Also on linkability and identification: >>>

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

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] [Last-Call] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

On Tue, Jan 07, 2020 at 02:47:02PM -0800, Eric Rescorla wrote a message of 310 lines which said: > Yeah, my point is that I don't agree with this. Right now there is a > lot of ISP centralization and the move of some of that traffic to > public resolvers potentially decreases centralization

Re: [dns-privacy] Last Call: (DNS Privacy Considerations) to Informational RFC

On Wed, Jan 01, 2020 at 10:45:58PM -0800, S Moonesamy wrote a message of 63 lines which said: > There are currently four (IETF) working groups focused on DNS with three of > them having privacy as part of their charter. doh, dnssd and dprive (plus dnsop)? > Section 1 of the draft has a

Re: [dns-privacy] [Last-Call] last call review of draft-ietf-dprive-rfc7626-bis-03

On Thu, Jan 9, 2020 at 10:30 AM Eric Rescorla wrote: > > On Thu, Jan 9, 2020 at 10:02 AM Sara Dickinson wrote: > >> >> It means a standards compliant DoT implementation will have no client >> identifiers, a standards compliant DoH implementation is free to (and >> likely) to include them. >> >

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] [Last-Call] Review of draft-ietf-dprive-rfc7626-bis-03

On Thu, Jan 9, 2020 at 10:03 AM Sara Dickinson wrote: > > > On 7 Jan 2020, at 22:51, Eric Rescorla wrote: > > > > On Tue, Jan 7, 2020 at 10:38 AM Sara Dickinson wrote: > >> >> >> On 31 Dec 2019, at 14:45, Eric Rescorla wrote: >> >> >> > > > >> >>> Also on linkability and identification: >>>