[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IANA action state changed to "RFC-Ed-Ack"
Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IANA action state changed to "Waiting on RFC Editor"
Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IANA action state changed to "In Progress"
Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IANA action state changed to "Waiting on Authors"
Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IANA action state changed to "In Progress"
Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IESG state changed:

New State: Approved-announcement to be sent

(The previous state was Approved-announcement to be sent::AD Followup)

After verifying that the Alvaro & Francesca COMMENT on section 5.3.3 is indeed 
fixed in this version.

Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Christian Huitema]

We just published a new version of the draft, 
https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/. We believe 
this new version addresses the comments received during IESG review. The 
changes were done in a series of pull request in our depot, visible 
here: https://github.com/huitema/dnsoquic/pulls?q=is%3Apr. We collected 
all the ballot reports, isolated the issues, and in most cases just 
fixed them. There were just very exceptions, in which case we contacted 
the individual IESG members and got them to agree that no change was 
actually requested. As eric wrote, "addressing [ these points ] improved 
the quality of the documents." Thanks to the IESG members for all the 
feedback.


-- Christian Huitema

On 3/15/2022 3:40 PM, Christian Huitema wrote:
Pull request https://github.com/huitema/dnsoquic/pull/159 addresses 
the second comment from Francesca's review, and the similar comment 
from Alvaro's review. It provides an alternative to "SHOULD forcibly 
abort the connection using QUIC's CONNECTION_CLOSE mechanism", by 
specifying that peers encountering fatal errors MAY silently abandon 
the connection. This is in fact always an option, peers may silently 
hang up at any time. In the case of such fatal errors, there is a 
trade-off between silent close and explicit close, which provides more 
information to the offending node but uses more of the local resource.


-- Christian Huitema

On 3/15/2022 11:39 AM, Christian Huitema wrote:

I have entered issues in our repo for all the reviews by IESG members.

Ben Kaduk submitted an editorial PR, and it was accepted.
There is another PR being processed to address the clarification on 
usage of 0RTT required by Ben and Lars -- 
https://github.com/huitema/dnsoquic/pull/158. Please review.

I will start another PR addressing Francesca and Alvaro's point.
After that, we may need an editorial pass for the other comments.
The goal should be to have a draft ready when the publishing window 
reopens.


-- Christian Huitema

On 3/15/2022 8:59 AM, Eric Vyncke (evyncke) wrote:

Dear authors,

The revised I-D should mainly address Francesca Palombini's 2nd 
COMMENT point (which was also raised by Alvaro Retana). Both of them 
told me that they were about to raise a blocking DISCUSS on this 
specific point, so let's address is. It is mainly about either 
changing a SHOULD into a MUST or explaining when the SHOULD can be 
ignored.


Of course, addressing the other points would improve the quality of 
the documents.


Once a revised I-D addressing Francesca's point, I am approving the 
document and sending it to the RFC Editor.


Regards

-éric


-Original Message-
From: IETF Secretariat 
Date: Thursday, 10 March 2022 at 16:21
To: "br...@innovationslab.net" , 
"dns-privacy@ietf.org" , 
"dprive-cha...@ietf.org" , 
"draft-ietf-dprive-dnsoq...@ietf.org" 
, Eric Vyncke 
Subject: Datatracker State Update Notice: 



 IESG state changed:

 New State: Approved-announcement to be sent::Revised I-D Needed

 (The previous state was IESG Evaluation)


 Datatracker URL: 
https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/






___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Christian Huitema]

Pull request https://github.com/huitema/dnsoquic/pull/159 addresses the 
second comment from Francesca's review, and the similar comment from 
Alvaro's review. It provides an alternative to "SHOULD forcibly abort 
the connection using QUIC's CONNECTION_CLOSE mechanism", by specifying 
that peers encountering fatal errors MAY silently abandon the 
connection. This is in fact always an option, peers may silently hang up 
at any time. In the case of such fatal errors, there is a trade-off 
between silent close and explicit close, which provides more information 
to the offending node but uses more of the local resource.


-- Christian Huitema

On 3/15/2022 11:39 AM, Christian Huitema wrote:

I have entered issues in our repo for all the reviews by IESG members.

Ben Kaduk submitted an editorial PR, and it was accepted.
There is another PR being processed to address the clarification on 
usage of 0RTT required by Ben and Lars -- 
https://github.com/huitema/dnsoquic/pull/158. Please review.

I will start another PR addressing Francesca and Alvaro's point.
After that, we may need an editorial pass for the other comments.
The goal should be to have a draft ready when the publishing window 
reopens.


-- Christian Huitema

On 3/15/2022 8:59 AM, Eric Vyncke (evyncke) wrote:

Dear authors,

The revised I-D should mainly address Francesca Palombini's 2nd 
COMMENT point (which was also raised by Alvaro Retana). Both of them 
told me that they were about to raise a blocking DISCUSS on this 
specific point, so let's address is. It is mainly about either 
changing a SHOULD into a MUST or explaining when the SHOULD can be 
ignored.


Of course, addressing the other points would improve the quality of 
the documents.


Once a revised I-D addressing Francesca's point, I am approving the 
document and sending it to the RFC Editor.


Regards

-éric


-Original Message-
From: IETF Secretariat 
Date: Thursday, 10 March 2022 at 16:21
To: "br...@innovationslab.net" , 
"dns-privacy@ietf.org" , 
"dprive-cha...@ietf.org" , 
"draft-ietf-dprive-dnsoq...@ietf.org" 
, Eric Vyncke 
Subject: Datatracker State Update Notice: 



 IESG state changed:

 New State: Approved-announcement to be sent::Revised I-D Needed

 (The previous state was IESG Evaluation)


 Datatracker URL: 
https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/






___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Christian Huitema]

I have entered issues in our repo for all the reviews by IESG members.

Ben Kaduk submitted an editorial PR, and it was accepted.
There is another PR being processed to address the clarification on 
usage of 0RTT required by Ben and Lars -- 
https://github.com/huitema/dnsoquic/pull/158. Please review.

I will start another PR addressing Francesca and Alvaro's point.
After that, we may need an editorial pass for the other comments.
The goal should be to have a draft ready when the publishing window reopens.

-- Christian Huitema

On 3/15/2022 8:59 AM, Eric Vyncke (evyncke) wrote:

Dear authors,

The revised I-D should mainly address Francesca Palombini's 2nd COMMENT point 
(which was also raised by Alvaro Retana). Both of them told me that they were 
about to raise a blocking DISCUSS on this specific point, so let's address is. 
It is mainly about either changing a SHOULD into a MUST or explaining when the 
SHOULD can be ignored.

Of course, addressing the other points would improve the quality of the 
documents.

Once a revised I-D addressing Francesca's point, I am approving the document 
and sending it to the RFC Editor.

Regards

-éric


-Original Message-
From: IETF Secretariat 
Date: Thursday, 10 March 2022 at 16:21
To: "br...@innovationslab.net" , "dns-privacy@ietf.org" , 
"dprive-cha...@ietf.org" , "draft-ietf-dprive-dnsoq...@ietf.org" 
, Eric Vyncke 
Subject: Datatracker State Update Notice: 

 IESG state changed:

 New State: Approved-announcement to be sent::Revised I-D Needed

 (The previous state was IESG Evaluation)


 Datatracker URL: 
https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/





___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Vyncke (evyncke)]

Dear authors,

The revised I-D should mainly address Francesca Palombini's 2nd COMMENT point 
(which was also raised by Alvaro Retana). Both of them told me that they were 
about to raise a blocking DISCUSS on this specific point, so let's address is. 
It is mainly about either changing a SHOULD into a MUST or explaining when the 
SHOULD can be ignored.

Of course, addressing the other points would improve the quality of the 
documents.

Once a revised I-D addressing Francesca's point, I am approving the document 
and sending it to the RFC Editor.

Regards

-éric


-Original Message-
From: IETF Secretariat 
Date: Thursday, 10 March 2022 at 16:21
To: "br...@innovationslab.net" , 
"dns-privacy@ietf.org" , "dprive-cha...@ietf.org" 
, "draft-ietf-dprive-dnsoq...@ietf.org" 
, Eric Vyncke 
Subject: Datatracker State Update Notice: 

IESG state changed:

New State: Approved-announcement to be sent::Revised I-D Needed

(The previous state was IESG Evaluation)


Datatracker URL: 
https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/



___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IESG state changed:

New State: Approved-announcement to be sent::Revised I-D Needed

(The previous state was IESG Evaluation)


Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IANA review state changed to "IANA OK - Actions Needed"
Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IANA review state changed to "IANA - Not OK"
Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IESG state changed:

New State: Last Call Requested

(The previous state was Waiting for Writeup::AD Followup)

As RFC 8467 is now a normative reference and as the text of section 6.4 
(padding) has changed since the first IETF Last Call, I am requested a second 
IETF Last Call.

Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IESG state changed:

New State: Waiting for Writeup::Revised I-D Needed

(The previous state was Waiting for Writeup)

Need to address the TSVART review, downref added to RFC 8467 (will require 
another IETF LC possibly 1 week long only)

Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IANA review state changed to "IANA - Not OK"
Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IESG state changed:

New State: Last Call Requested

(The previous state was AD Evaluation::AD Followup)


Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IESG state changed:

New State: AD Evaluation::Revised I-D Needed

(The previous state was AD Evaluation)

Sent comments to the WG list: 
https://mailarchive.ietf.org/arch/msg/dns-privacy/mJ99vYiHiHuAFHxg3l5sioS8mHk/

Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IESG state changed:

New State: AD Evaluation

(The previous state was Publication Requested)


Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IANA action state changed to "No IANA Actions"
Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IANA action state changed to "In Progress"
Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IESG state changed:

New State: IESG Evaluation::Revised I-D Needed

(The previous state was IESG Evaluation::AD Followup)

Alissa Cooper's DISCUSS points are still to be addressed.

Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IESG state changed:

New State: IESG Evaluation::Revised I-D Needed

(The previous state was IESG Evaluation)


Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Rob Sayre]

While it might be too late to debate this point, I would say the paragraph
that begins with "Users will only be aware of..." and the following
bullet points could be dropped. It seems to state that users can't change
settings if there are no settings three times (this seems obvious). One
bullet point mentions a "change in default". I do not think these settings
represent a "default", although they may represent the status quo on some
systems (but not all).

The third paragraph says "Application-specific changes to default
destinations for users' DNS" seems to concern an OS API subject (something
for POSIX etc), rather than an IETF protocol issue.

thanks,
Rob


On Mon, Sep 28, 2020 at 2:26 AM IETF Secretariat <
ietf-secretariat-re...@ietf.org> wrote:

> IESG state changed:
>
> New State: IESG Evaluation
>
> (The previous state was Waiting for AD Go-Ahead::AD Followup)
>
>
> Datatracker URL:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/
>
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IESG state changed:

New State: IESG Evaluation

(The previous state was Waiting for AD Go-Ahead::AD Followup)


Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IESG state changed:

New State: Waiting for AD Go-Ahead::Revised I-D Needed

(The previous state was Waiting for AD Go-Ahead::AD Followup)


Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Rob Sayre]

On Wed, May 13, 2020 at 4:58 PM Christian Huitema 
wrote:

>
> On 5/13/2020 3:19 PM, Andrew Campling wrote:
>
> I also note that RFC 3552 (Guidelines for Writing RFC Text on Security
> Considerations) includes section 2.3 on systems security so does indeed
> look beyond the network.  So, alongside RFC 7754 and RFC 6973, there seem
> to be a good number of examples where the IETF has reached consensus on
> documents with scope that extends beyond the network.  I’m unclear why this
> one should not.
>
>
> Because we do not in fact have consensus on what to say.
>

Agree. There doesn't even seem to be consensus that this part of the
document concerns security. A lot of the terms in this thread, like "user"
and "security", are being stretched pretty far.

Some sections of this document read more like industry advocacy than an
IETF document to me. Advocacy is fine, but I am not sure it belongs in an
RFC.

thanks,
Rob
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Brian Dickson]

On Tue, May 12, 2020 at 8:13 PM Ben Schwartz  wrote:

>
>
> On Tue, May 12, 2020 at 8:15 AM Vittorio Bertola  40open-xchange@dmarc.ietf.org> wrote:
>
>>
>> Il 11/05/2020 21:35 Christian Huitema  ha scritto:
>>
>> I found the discussion of application embedded resolvers bizarre. It
>> speaks of applications in general, but the way the text is set-up appears
>> to be a specific dig against Mozilla. Look at the text: "popular
>> applications directing DNS traffic by default to specific dominant
>> resolvers". It boils down to accusing some unnamed application of
>> deliberately contributing to centralization. I find that problematic, and
>> also very imprecise.. I think this should be rewritten in a much more
>> neutral way.
>>
>> I think this section has already been rewritten at least half a dozen
>> times, and every time there was a claim that it is not neutral (sometimes
>> even on text that previously seemed to be ok). Every time the authors put
>> the effort to rewrite it once again according to the comment, and every
>> time a new comment comes in saying that this is not enough. I admire their
>> patience.
>>
>> In any case, I don't know Mozilla's view on whether this is a specific
>> dig against them, but it is meant as a discussion on privacy impacts of a
>> specific deployment model, not of a specific company's policy. These
>> privacy impacts, even if with very variable views, have been the subject of
>> many conferences, articles and talks in the last couple of years - they
>> were not discovered in this document, and it would be weird if they were
>> omitted from a discussion on DNS privacy released in 2020. The fact that
>> Mozilla is at this time the only company adopting that model is just
>> coincidental, apart from perhaps reflecting the fact that others think that
>> that model is not a particularly good idea.
>>
>> In a modern environment, the concept of host is very fuzzy. We get all
>> kinds of special devices. We also get containers or virtual machines
>> running inside hosts. A browser is in practice such a container. There is
>> not a difference of nature between a separate subsystem like a browser
>> environment and a separate device. If a browser embeds its own stub
>> resolver, users can configure the resolver of their choice in much the same
>> way that they can configure the resolver of their choice using a device
>> configuration UI. There are differences in management, but these
>> differences fall largely outside the scope of the DNS privacy draft.
>>
>> In both cases, users are very likely to configure a well-known service.
>> There is not much the difference between setting the device's preferred
>> resolver to 8.8.8.8 and setting the browser's choice to "Google DNS"? In
>> both cases, the centralization effect results from the popularity of the
>> service, unless you are specifically accusing Mozilla of conspiring to
>> centralize the DNS. And a privacy RFC is not the right place to do that.
>>
>> You seem to miss the point, which is not about users setting their
>> preferred resolver at the application level, but about applications that by
>> default ignore the resolver settings in the device and pick their own
>> preferred resolver independently from the user.
>>
>> In a market in which there are few choices, indeed this behaviour
>> promotes centralization: we know that most users do not change the
>> defaults, and if most users of a popular application start using a single
>> resolver in place of a broad set of local resolvers scattered around the
>> Internet, of course the resulting traffic pattern is more centralized.
>>
>> We also know that centralization of the DNS is potentially a privacy
>> threat, as it makes it easier to track and correlate multiple activities by
>> the same individual. This does not seem contentious - it was actually the
>> first example in last year's IAB "DEDR" workshop charter.
>>
>
> That seems quite contentious to me.  Decentralization of the DNS is _also_
> a privacy threat: running your own recursive leaks your IP to every
> authoritative (far worse than ECS!), pinning yourself to a unique recursive
> makes you uniquely identifiable as you move across the network, and using a
> recursive whose identity is unknown is obviously a privacy concern.
>
> There are many possible resolution configurations, and none of them offer
> perfect privacy.  The exact tradeoffs between them are very much in flux as
> the relevant standards and practices evolve.  If the draft tries to cover
> this topic it should present all of the risks in these different
> configurations, but I think it would probably be wiser to avoid claims
> about the privacy properties of deployment architectures.
>
>
Please let me point out that there is a repeated false dichotomy, regarding
running your own resolver software.

There is one specific mode, which most resolver software supports:
forwarder.
The resolution chain would then be application - stub software - local

Re: [dns-privacy] Datatracker State Update Notice:

[Christian Huitema]

On 5/13/2020 3:19 PM, Andrew Campling wrote:
> I also note that RFC 3552 (Guidelines for Writing RFC Text on Security
> Considerations) includes section 2.3 on systems security so does
> indeed look beyond the network.  So, alongside RFC 7754 and RFC 6973,
> there seem to be a good number of examples where the IETF has reached
> consensus on documents with scope that extends beyond the network. 
> I’m unclear why this one should not.


Because we do not in fact have consensus on what to say.

Also, if we want to tackle the topic of centralization, it should
probably be best to decouple it from client system architecture. There
are many forces pushing centralization, and it is very unclear that
application configuration is the worst of them. For example, we see many
ISPs subcontracting their DNS services to big centralized providers. We
also see centralization of authoritative servers, with many web sites
getting their DNS services from big providers. We see centralization in
the TLD services, with many TLD registries  subcontracting operations to
specialized providers.

Which means it is probably much simpler to leave the client system
architecture discussions out of the rfc7626-bis draft, and start a
separate effort to describe centralization issues.

-- Christian Huitema

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Andrew Campling]

On 13/05/2020 11:27 Vittorio Bertola  wrote:



>> Il 12/05/2020 17:18 Stephane Bortzmeyer 
>> mailto:bortzme...@nic.fr>> ha scritto:

>>

>> Yes, and I think I know now the root of the problem. 7626bis tries to

>> go too far and, instead of discussing the DNS protocol and its privacy

>> issues, now goes into end hosts and discuss what is done inside the

>> machine, and what should be done. This is certainy interesting, and it

>> certainly has consequences on privacy, user control, etc but:

>>

>> 1) It is a bit outside IETF's domain, since it is not inside the

>> network,

>

>I disagree. There are IETF documents that provide policy-level analysis of 
>complex

>technical issues and do so throughout the entire network architecture, both in 
>terms

>of layers and in terms of hosts. For example, RFC 7754 has an entire section 
>devoted

>to what happens within the endpoints and within applications that run on them.

>

>Also, RFC 6973, which is the document that this draft tries to apply, has an 
>entire

>section of the guidelines (7.2) that instructs to discuss issues of user 
>control, which

>is what 6.1.1.2 deals with. Actually, the first point of the section is:

>

> "What controls or consent mechanisms does the

>  protocol define or require before personal data or identifiers

>  are shared or exposed via the protocol?  If no such mechanisms or

> controls are specified, is it expected that control and consent

>will be handled outside of the protocol?"

>

>There even is an explicit reference to discussing how control and consent is 
>handled outside of the protocol.



I also note that RFC 3552 (Guidelines for Writing RFC Text on Security 
Considerations) includes section 2.3 on systems security so does indeed look 
beyond the network.  So, alongside RFC 7754 and RFC 6973, there seem to be a 
good number of examples where the IETF has reached consensus on documents with 
scope that extends beyond the network.  I’m unclear why this one should not.





Andrew




___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Andrew Campling]

At 13 May 2020 18:10, S Moonesamy  wrote:



>Hi Ben,

>At 08:12 PM 12-05-2020, Ben Schwartz wrote:

>>That seems quite contentious to me.  Decentralization of the DNS is

>>_also_ a privacy threat: running your own recursive leaks your IP to

>>every authoritative (far worse than ECS!), pinning yourself to a unique

>>recursive makes you uniquely identifiable as you move across the

>>network, and using a recursive whose identity is unknown is obviously a

>>privacy concern.

>

>I commented about "centralization" within the context of IETF work on

>several occasions.  My opinion is likely clouded by past experience.

>With respect to privacy, I spent around two years getting the IESG to

>take it seriously.

>

>From what I recall of what is written in RFCs, DNS is described as a

>distributed database.  There are some advantages of it being distributed,

>or if I may say so, decentralized.  For example, some countries might

>wish to have some degree of control over their ccTLD.  System failures

>do not generally affect a majority of users.

>

>There are obviously privacy implications.  Within an IETF context, it would

>make surveillance easier if everything is one provider.



I note that draft-arkko-arch-infrastructure-centralisation made some helpful 
observations regarding the dangers of centralisation, with specific points 
relating to DNS.  It included the following points in the recommendation 
section: "Where such centralised points are created, they will eventually fail, 
or they will be misused through surveillance or legal actions regardless of the 
best efforts of the Internet community.  The best defense to data leak is to 
avoid creating that data store to begin with".  This seems to be good advice to 
me.



Andrew
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[S Moonesamy]

Hi Ben,
At 08:12 PM 12-05-2020, Ben Schwartz wrote:
That seems quite contentious to me.  Decentralization of the DNS is 
_also_ a privacy threat: running your own recursive leaks your IP to 
every authoritative (far worse than ECS!), pinning yourself to a 
unique recursive makes you uniquely identifiable as you move across 
the network, and using a recursive whose identity is unknown is 
obviously a privacy concern.


I commented about "centralization" within the context of IETF work on 
several occasions.  My opinion is likely clouded by past 
experience.  With respect to privacy, I spent around two years 
getting the IESG to take it seriously.


From what I recall of what is written in RFCs, DNS is described as a 
distributed database.  There are some advantages of it being 
distributed, or if I may say so, decentralized.  For example, some 
countries might wish to have some degree of control over their 
ccTLD.  System failures do not generally affect a majority of users.


There are obviously privacy implications.  Within an IETF context, it 
would make surveillance easier if everything is one provider.


Regards,
S. Moonesamy 


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Vittorio Bertola]

> Il 12/05/2020 17:18 Stephane Bortzmeyer  ha scritto:
> 
> Yes, and I think I know now the root of the problem. 7626bis tries to
> go too far and, instead of discussing the DNS protocol and its privacy
> issues, now goes into end hosts and discuss what is done inside the
> machine, and what should be done. This is certainy interesting, and it
> certainly has consequences on privacy, user control, etc but:
> 
> 1) It is a bit outside IETF's domain, since it is not inside the
> network,

I disagree. There are IETF documents that provide policy-level analysis of 
complex technical issues and do so throughout the entire network architecture, 
both in terms of layers and in terms of hosts. For example, RFC 7754 has an 
entire section devoted to what happens within the endpoints and within 
applications that run on them.

Also, RFC 6973, which is the document that this draft tries to apply, has an 
entire section of the guidelines (7.2) that instructs to discuss issues of user 
control, which is what 6.1.1.2 deals with. Actually, the first point of the 
section is:

  "What controls or consent mechanisms does the
   protocol define or require before personal data or identifiers
   are shared or exposed via the protocol?  If no such mechanisms or
   controls are specified, is it expected that control and consent
   will be handled outside of the protocol?"

There even is an explicit reference to discussing how control and consent is 
handled outside of the protocol.

> 2) There is clearly no consensus inside IETF about it.

This is a different matter. However, there is also no consensus on dropping 
this part - certainly I would not agree. It does not make sense to have a "DNS 
Privacy Considerations" document that ignores parts of the problem. These 
issues are so interlinked that there is no clear single "more privacy" switch. 
Each of the technical solutions, both within the protocol and within its 
clients, could provide more or less privacy depending on a number of other 
considerations, some of which are not about technical protocol design but are 
nonetheless relevant. Either you analyze them in full, or the analysis is going 
to be incorrect and misleading.

> My personal opinion is now that the best way out of the problem is to
> drop discussions about internal (to the end host) issues.

Again, I disagree. The solution is to find reasonable compromise text that can 
be acceptable for all while not making anyone really happy. What was in the 
last draft seemed to me quite near to that goal.

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Vittorio Bertola]

> Il 13/05/2020 05:12 Ben Schwartz  ha 
> scritto:
> 
> 
> 
> 
> On Tue, May 12, 2020 at 8:15 AM Vittorio Bertola  40open-xchange@dmarc.ietf.org mailto:40open-xchange@dmarc.ietf.org > 
> wrote:
> 
> > > We also know that centralization of the DNS is 
> potentially a privacy threat, as it makes it easier to track and correlate 
> multiple activities by the same individual. This does not seem contentious - 
> it was actually the first example in last year's IAB "DEDR" workshop charter.
> > 
> > > 
> That seems quite contentious to me.  Decentralization of the DNS is 
> _also_ a privacy threat: running your own recursive leaks your IP to every 
> authoritative (far worse than ECS!), pinning yourself to a unique recursive 
> makes you uniquely identifiable as you move across the network, and using a 
> recursive whose identity is unknown is obviously a privacy concern.
> 
I agree with that, but the two statements are not incompatible with each other. 
Also, I will note that you are comparing oranges with apples: "centralization 
of the DNS", as used above, is not about replacing your own recursive with a 
third party one, but about replacing in the overall DNS resolution system many 
independent third party resolvers with a single third party resolver that 
serves many more users. So "decentralization of the DNS" would mean promoting 
the existence of a higher number of independent resolvers and letting users 
pick easily and safely the one(s) they want to use, and in that sense it would 
clearly reduce mass surveillance opportunities, at least until you get to a 
situation in which each resolver has so few users that it can be used to 
identify them (which is not a common situation for the average Internet user).

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Stephane Bortzmeyer]

On Mon, May 11, 2020 at 12:35:11PM -0700,
 Christian Huitema  wrote 
 a message of 294 lines which said:

> The paragraph in section 5.1 seems to imply that embedding a
> recursive resolver in the end point or close to reduces the privacy
> attack surface:

Note that it was already in RFC 7626 (which does not mean it was
right). I agree with you that there is a weakness in the reasoning (a
sniffer located between such a resolver and the rest of the Internet
would see a lot since a one-user resolver may have little caching).

I think the problem is that the RFC (in 7626-ter?) should better
separate upstream surveillance (before the resolver), downstream
surveillance (after the resolver) and internal surveillance (inside
the resolver). Using a in-host resolver decreases upstream
surveillance and suppresses internal surveillance, but does little for
downstream surveillance (because of limited caching). Using a remote
resolver with DoT or DoH to reach it may expose to internal
surveillance (if the trust in this resolver is misplaced) but
decreases upstream and downstream (because of caching) surveillance.

> At a minimum, I would like to see a forward pointer to section 6.2
> in the recursive resolver on device paragraph. A general warning
> that this is a trade-off would be nice too.

I agree and I suggest "As it is often the case with privacy, there is
a trade-off here. A local (to the user's machine or LAN) resolver
reduces the risk that the resolver's administrator read the user's DNS
traffic, but it does not protect a lot against later sniffing, done at
the place where the resolver talks with authoritative name servers."

> I found the discussion of application embedded resolvers bizarre.

See 

I know think that it is indeed on the wrong track.

> In a modern environment, the concept of host is very fuzzy. We get all
> kinds of special devices. We also get containers or virtual machines
> running inside hosts. A browser is in practice such a container.

I agree that OSvsApplication it should not be in this draft.

> As for section 6.1.1.2, I would scratch most of it,

I completely agree.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Stephane Bortzmeyer]

On Tue, May 12, 2020 at 02:14:43PM +0200,
 Vittorio Bertola  wrote 
 a message of 144 lines which said:

> Every time the authors put the effort to rewrite it once again
> according to the comment, and every time a new comment comes in
> saying that this is not enough. I admire their patience.

Not "the authors", just Sara, she was the one patient and
hard-working, the other author was lazy.

> I think this section has already been rewritten at least half a
> dozen times, and every time there was a claim that it is not neutral
> (sometimes even on text that previously seemed to be ok).

Yes, and I think I know now the root of the problem. 7626bis tries to
go too far and, instead of discussing the DNS protocol and its privacy
issues, now goes into end hosts and discuss what is done inside the
machine, and what should be done. This is certainy interesting, and it
certainly has consequences on privacy, user control, etc but:

1) It is a bit outside IETF's domain, since it is not inside the
network,
2) There is clearly no consensus inside IETF about it.

My personal opinion is now that the best way out of the problem is to
drop discussions about internal (to the end host) issues.

> These privacy impacts, even if with very variable views, have been
> the subject of many conferences, articles and talks in the last
> couple of years

Which clearly demonstrated that there is no consensus about it.

> You seem to miss the point, which is not about users setting their
> preferred resolver at the application level, but about applications
> that by default ignore the resolver settings in the device and pick
> their own preferred resolver independently from the user.

There is zero difference between an user using the resolver configured
in the OS and the user using the resolver configured in the
application. In both cases, the user uses the default value, not
knowing how to change it or if he/she should change it, or even that
it exists.

Also, Christian is right here: there is no clear definition of OS
vs. application and creating one seems to me quite outside of IETF's
realm.

> I am also puzzled by the fact that this draft was actually in last
> call six months ago, and it only received a single objection just
> before the deadline, and since then we have entered an endless cycle
> changing it again and again and again. I did my best to help with
> compromise text as requested but I do not understand where this
> process is going.

See my suggestion: IETF should stop discussing relationship between OS
and apps (which is fuzzy, anyway) and should focus on network
protocols.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Vittorio Bertola]

> Il 11/05/2020 21:35 Christian Huitema  ha scritto:
> 
> 
> I found the discussion of application embedded resolvers bizarre. It 
> speaks of applications in general, but the way the text is set-up appears to 
> be a specific dig against Mozilla. Look at the text: "popular applications 
> directing DNS traffic by default to specific dominant resolvers". It boils 
> down to accusing some unnamed application of deliberately contributing to 
> centralization. I find that problematic, and also very imprecise. I think 
> this should be rewritten in a much more neutral way.
> 
I think this section has already been rewritten at least half a dozen times, 
and every time there was a claim that it is not neutral (sometimes even on text 
that previously seemed to be ok). Every time the authors put the effort to 
rewrite it once again according to the comment, and every time a new comment 
comes in saying that this is not enough. I admire their patience.

In any case, I don't know Mozilla's view on whether this is a specific dig 
against them, but it is meant as a discussion on privacy impacts of a specific 
deployment model, not of a specific company's policy. These privacy impacts, 
even if with very variable views, have been the subject of many conferences, 
articles and talks in the last couple of years - they were not discovered in 
this document, and it would be weird if they were omitted from a discussion on 
DNS privacy released in 2020. The fact that Mozilla is at this time the only 
company adopting that model is just coincidental, apart from perhaps reflecting 
the fact that others think that that model is not a particularly good idea.


> 
> In a modern environment, the concept of host is very fuzzy. We get all 
> kinds of special devices. We also get containers or virtual machines running 
> inside hosts. A browser is in practice such a container. There is not a 
> difference of nature between a separate subsystem like a browser environment 
> and a separate device. If a browser embeds its own stub resolver, users can 
> configure the resolver of their choice in much the same way that they can 
> configure the resolver of their choice using a device configuration UI. There 
> are differences in management, but these differences fall largely outside the 
> scope of the DNS privacy draft.
> 
> In both cases, users are very likely to configure a well-known service. 
> There is not much the difference between setting the device's preferred 
> resolver to 8.8.8.8 and setting the browser's choice to "Google DNS"? In both 
> cases, the centralization effect results from the popularity of the service, 
> unless you are specifically accusing Mozilla of conspiring to centralize the 
> DNS. And a privacy RFC is not the right place to do that.
> 
You seem to miss the point, which is not about users setting their preferred 
resolver at the application level, but about applications that by default 
ignore the resolver settings in the device and pick their own preferred 
resolver independently from the user.

In a market in which there are few choices, indeed this behaviour promotes 
centralization: we know that most users do not change the defaults, and if most 
users of a popular application start using a single resolver in place of a 
broad set of local resolvers scattered around the Internet, of course the 
resulting traffic pattern is more centralized.

We also know that centralization of the DNS is potentially a privacy threat, as 
it makes it easier to track and correlate multiple activities by the same 
individual. This does not seem contentious - it was actually the first example 
in last year's IAB "DEDR" workshop charter.

Moreover, this potential downside for privacy can be entirely countered by 
increased privacy protections offered by the new operator, and this is clearly 
stated in the final paragraph.

The central paragraphs were initially meant to say that, to preserve the user's 
privacy, the user should always be given controls to set the resolver. This is 
in line with the basic principle of most privacy-protecting policy frameworks, 
i.e. user consent.

However, the current text just says that "if" we wanted to give users the same 
degree of control they currently have in basically any consumer-oriented 
operating system, then applications should provide users with controls (any 
control goes, even if hidden under a 3-click-deep configuration hierarchy, as 
you have to do today if you really want to reject advertising cookies on the 
average commercial website). Then, the text adds that if applications don't do 
it, users might not... be able to control their resolver.

There is not even any more a stance that says that users should be able to 
choose where their DNS queries go, or that the lack of such choice is in itself 
a privacy problem. From the perspective of a privacy advocate, this section is 
now quite watered down.

I am also puzzled by the fact that this draft was 

Re: [dns-privacy] Datatracker State Update Notice:

[Christian Huitema]

On 5/11/2020 7:27 AM, Sara Dickinson wrote:
>> Well, the issue is that this text is being used to contrast
>> application-specific settings to OS ones, so I'm not sure how not to
>> get into it. 
>
> Suggest modify the text about the OS settings to:
>
> “ All major OS's expose the system DNS settings and allow users
> to manually override them if desired (on some systems this might be
> limited to only those users who have administrator rights.)”
>
> And update the first and second paragraphs of this section to the
> following:
>
> “An increasing number of applications are offering
> application-specific DNS resolution settings, rather than
> defaulting to using only the system resolver. It should be noted that
> the privileges required to install such an application vary and so it
> may be possible to bypass administrator level controls on OS DNS
> resolver settings via this route. Many such applications offer
> encrypted transports - for these applications a variety of
> heuristics and resolvers are available including hard-coded lists of
> recognized DoH/DoT servers."
>
> In order for users that are able to update their OS DNS resolver
> settings to have the ability to manage the DNS resolver settings for
> each individual application in a similar fashion, each application
> would need to expose the default settings
> to the user, provide a configuration interface to change them, and
> support configuration of user specified resolvers."


This discussion pushed me to review draft-ietf-dprive-rfc7626-bis-05. I
do like the general structure of the document, but I have two
observations -- a minor one first regarding recursive resolvers on the
end device, and a big sticking point with the discussion of resolvers
embedded in an application.

The paragraph in section 5.1 seems to imply that embedding a recursive
resolver in the end point or close to reduces the privacy attack surface:

   o  The recursive resolver can be on the end user's device.  In
  (currently) a small number of cases, individuals may choose to
  operate their own DNS resolver on their local machine.  In this
  case, the attack surface for the connection between the stub
  resolver and the caching resolver is limited to that single
  machine.

That's a very debatable statement. In the absence of encryption, the
only practical reduction in observable traffic is the amount of caching
performed in the device's resolver, and a caching stub resolver would
get similar reduction. In the presence of encryption, the multiple
connections between the local resolver and the authoritative servers
expose more data than encrypted traffic between stub and resolver. The
local recursive resolver will not expose data to a third party recursive
resolver, but it will expose data to authoritative resolvers, as
explained in section 6.2. At a minimum, I would like to see a forward
pointer to section 6.2 in the recursive resolver on device paragraph. A
general warning that this is a trade-off would be nice too.

I found the discussion of application embedded resolvers bizarre. It
speaks of applications in general, but the way the text is set-up
appears to be a specific dig against Mozilla. Look at the text: "popular
applications directing DNS traffic by default to specific dominant
resolvers". It boils down to accusing some unnamed application of
deliberately contributing to centralization. I find that problematic,
and also very imprecise. I think this should be rewritten in a much more
neutral way.

In a modern environment, the concept of host is very fuzzy. We get all
kinds of special devices. We also get containers or virtual machines
running inside hosts. A browser is in practice such a container. There
is not a difference of nature between a separate subsystem like a
browser environment and a separate device. If a browser embeds its own
stub resolver, users can configure the resolver of their choice in much
the same way that they can configure the resolver of their choice using
a device configuration UI. There are differences in management, but
these differences fall largely outside the scope of the DNS privacy draft.

In both cases, users are very likely to configure a well-known service.
There is not much the difference between setting the device's preferred
resolver to 8.8.8.8 and setting the browser's choice to "Google DNS"? In
both cases, the centralization effect results from the popularity of the
service, unless you are specifically accusing Mozilla of conspiring to
centralize the DNS. And a privacy RFC is not the right place to do that.

I would like to see the "popular applications" sentence rewritten in a
much more neutral way. Maybe something like:

* applications that embed their own stub resolvers and allow
configuration of the DNS resolver independently of system defaults.

And leave it at that. No innuendo, no allegations of hidden motives.

As for section 6.1.1.2, I would scratch most of it, maybe just keeping
the very 

Re: [dns-privacy] Datatracker State Update Notice:

[Sara Dickinson]

> On 11 May 2020, at 13:56, Eric Rescorla  wrote:
> 
> 
> 
> On Mon, May 11, 2020 at 5:34 AM Sara Dickinson  > wrote:
> 
> 
> > On 7 May 2020, at 17:41, Eric Rescorla  > > wrote:
> > 
> > Extensively trimming:
> > 
> > To be honest, this thread has gotten so long that I've lost
> > track of the various changes being proposed, so here's
> > my comments on the text as a whole.
> > 
> 
> To be honest, I really thought we had pretty much converged on some text that 
> had consensus for this section...
> 
> As I said at the beginning, i think it's generally problematic, for the 
> reasons below, but as you insist on keeping it, I'm giving it a close read, 
> and in that context, this framing is problematic.
> 
> 
> > > "An increasing number of applications are offering
> > > application-specific encrypted DNS resolution settings, rather than
> > > defaulting to using only the system resolver.  A variety of heuristics
> > > and resolvers are available in different applications including
> > > hard-coded lists of recognized DoH/DoT servers.
> > 
> > As I said earlier, I think this text is highly misleading.
> > There are at least two major loci of filtering via DNS:
> > 
> > 1. In the operating system itself via the system resolver
> >or hooks into that resolver.
> > 
> > 2. In the network via (a) the selected resolver or (b) on-path
> >filtering of the traffic to/from that resolver.
> > 
> > There are least three major application resolution technologies that
> > render one or more of these techniques ineffective:
> > 
> > 1. Using an application-level resolver which uses the system settings
> >[what Chrome currently does] bypasses (1)
> > 
> > 2. Using an application-level resolver which uses DoH/DoT to the
> >system configured resolver [what Edge and Chrome are experimenting
> >with] bypasses (1) and maybe 2(b) if the network config gets out of
> >sync (i.e., you don't want your system configured resolver to do
> >DoH/DoT if you use network-level filtering, but it's easy to see
> >how this can happen if (for instance) you just offer the the user
> >the ISP resolver and they start supporting DoH/DoT
> > 
> > 3. Using an application-level resolver which uses DoH/DoT to
> >an application-selected resolver [as in the Firefox TRR
> >system] bypasses all of these.
> > 
> > The key point is that a lot of filtering is broken by reasons
> > that have nothing to do with encrypted transport, and so
> > this text is misleading.
> 
> Somewhat confused here.. the text you quote above does not mention filtering 
> at all, was added in version -04 published in January and wasn’t referenced 
> at all in your first review of -04. Are you now saying you want this specific 
> text reworked?
> 
> The problem isn't this text specifically, it's that it's used in context for 
> a section talking about how DoH and DoT interfere with filtering, but, as 
> detailed above, that's only part of the story.
>  
> > > For users to have the ability to manage the DNS resolver settings for
> > > each individual application in a similar fashion to the OS DNS
> > > settings, each application would need to expose the default settings
> > > to the user, provide a configuration interface to change them, and
> > > support configuration of user specified resolvers.
> > 
> > This seems sort of true, though of course in some systems (I don't
> > know how common this is in the world of mostly single-user computers)
> > users actually can't change the system resolver settings.
> 
> We previously agreed text in section 6.1.1 that says both:
> 
> “ All major OS's expose the system DNS settings and allow users to
>manually override them if desired."
> 
> Yes, this is true as well. 
> 
> “The vast majority of users do not change their default system DNS
>settings and so implicitly accept the network settings for DNS."
> 
> Yes, I think this is true. 
> 
> 
> Getting into user specific authorisations around this isn’t something that 
> has been proposed in any comment before and I’m not sure how useful it is at 
> this point?
> 
> Well, the issue is that this text is being used to contrast 
> application-specific settings to OS ones, so I'm not sure how not to get into 
> it. 

Suggest modify the text about the OS settings to:

“ All major OS's expose the system DNS settings and allow users to manually 
override them if desired (on some systems this might be limited to only those 
users who have administrator rights.)”

And update the first and second paragraphs of this section to the following:

“An increasing number of applications are offering application-specific DNS 
resolution settings, rather than
defaulting to using only the system resolver. It should be noted that the 
privileges required to install such an application vary and so it may be 
possible to bypass administrator level controls on OS DNS resolver settings via 
this route. Many such 

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Rescorla]

On Mon, May 11, 2020 at 5:34 AM Sara Dickinson  wrote:

>
>
> > On 7 May 2020, at 17:41, Eric Rescorla  wrote:
> >
> > Extensively trimming:
> >
> > To be honest, this thread has gotten so long that I've lost
> > track of the various changes being proposed, so here's
> > my comments on the text as a whole.
> >
>
> To be honest, I really thought we had pretty much converged on some text
> that had consensus for this section...
>

As I said at the beginning, i think it's generally problematic, for the
reasons below, but as you insist on keeping it, I'm giving it a close read,
and in that context, this framing is problematic.


> > > "An increasing number of applications are offering
> > > application-specific encrypted DNS resolution settings, rather than
> > > defaulting to using only the system resolver.  A variety of heuristics
> > > and resolvers are available in different applications including
> > > hard-coded lists of recognized DoH/DoT servers.
> >
> > As I said earlier, I think this text is highly misleading.
> > There are at least two major loci of filtering via DNS:
> >
> > 1. In the operating system itself via the system resolver
> >or hooks into that resolver.
> >
> > 2. In the network via (a) the selected resolver or (b) on-path
> >filtering of the traffic to/from that resolver.
> >
> > There are least three major application resolution technologies that
> > render one or more of these techniques ineffective:
> >
> > 1. Using an application-level resolver which uses the system settings
> >[what Chrome currently does] bypasses (1)
> >
> > 2. Using an application-level resolver which uses DoH/DoT to the
> >system configured resolver [what Edge and Chrome are experimenting
> >with] bypasses (1) and maybe 2(b) if the network config gets out of
> >sync (i.e., you don't want your system configured resolver to do
> >DoH/DoT if you use network-level filtering, but it's easy to see
> >how this can happen if (for instance) you just offer the the user
> >the ISP resolver and they start supporting DoH/DoT
> >
> > 3. Using an application-level resolver which uses DoH/DoT to
> >an application-selected resolver [as in the Firefox TRR
> >system] bypasses all of these.
> >
> > The key point is that a lot of filtering is broken by reasons
> > that have nothing to do with encrypted transport, and so
> > this text is misleading.
>
> Somewhat confused here.. the text you quote above does not mention
> filtering at all, was added in version -04 published in January and wasn’t
> referenced at all in your first review of -04. Are you now saying you want
> this specific text reworked?
>

The problem isn't this text specifically, it's that it's used in context
for a section talking about how DoH and DoT interfere with filtering, but,
as detailed above, that's only part of the story.



> > > For users to have the ability to manage the DNS resolver settings for
> > > each individual application in a similar fashion to the OS DNS
> > > settings, each application would need to expose the default settings
> > > to the user, provide a configuration interface to change them, and
> > > support configuration of user specified resolvers.
> >
> > This seems sort of true, though of course in some systems (I don't
> > know how common this is in the world of mostly single-user computers)
> > users actually can't change the system resolver settings.
>
> We previously agreed text in section 6.1.1 that says both:
>
> “ All major OS's expose the system DNS settings and allow users to
>manually override them if desired."
>

Yes, this is true as well.

>
> “The vast majority of users do not change their default system DNS
>settings and so implicitly accept the network settings for DNS."
>

Yes, I think this is true.


Getting into user specific authorisations around this isn’t something that
> has been proposed in any comment before and I’m not sure how useful it is
> at this point?
>

Well, the issue is that this text is being used to contrast
application-specific settings to OS ones, so I'm not sure how not to get
into it.



> > > The system resolver resolution path is sometimes used to configure
> > > additional DNS controls e.g. query logging, domain based query
> > > re-direction or filtering.
> >
> > This conflates the network and in-OS filtering discussed above,
> > which I really think needs expansion.
>
> Suggest:
>
> “The system resolver resolution path is sometimes used to configure
> additional device based DNS controls (distinct from any controls
> implemented at the network level) e.g. local query logging, domain based
> query re-direction or filtering."
>

Well, I agree with this parenthetical, but then it just reinforces my point
that this not being about *encrypted* DNS but rather about
application-specific DNS, because this text then becomes about method (1)
and therefore implicates any application-level resolver, encrypted or not.


> >
> >
> > > If all of the 

Re: [dns-privacy] Datatracker State Update Notice:

[Sara Dickinson]

> On 7 May 2020, at 17:41, Eric Rescorla  wrote:
> 
> Extensively trimming:
> 
> To be honest, this thread has gotten so long that I've lost
> track of the various changes being proposed, so here's
> my comments on the text as a whole.
> 

To be honest, I really thought we had pretty much converged on some text that 
had consensus for this section...

> 
> 
> > "An increasing number of applications are offering
> > application-specific encrypted DNS resolution settings, rather than
> > defaulting to using only the system resolver.  A variety of heuristics
> > and resolvers are available in different applications including
> > hard-coded lists of recognized DoH/DoT servers.
> 
> As I said earlier, I think this text is highly misleading.
> There are at least two major loci of filtering via DNS:
> 
> 1. In the operating system itself via the system resolver
>or hooks into that resolver.
> 
> 2. In the network via (a) the selected resolver or (b) on-path
>filtering of the traffic to/from that resolver.
> 
> There are least three major application resolution technologies that
> render one or more of these techniques ineffective:
> 
> 1. Using an application-level resolver which uses the system settings
>[what Chrome currently does] bypasses (1)
> 
> 2. Using an application-level resolver which uses DoH/DoT to the
>system configured resolver [what Edge and Chrome are experimenting
>with] bypasses (1) and maybe 2(b) if the network config gets out of
>sync (i.e., you don't want your system configured resolver to do
>DoH/DoT if you use network-level filtering, but it's easy to see
>how this can happen if (for instance) you just offer the the user
>the ISP resolver and they start supporting DoH/DoT
> 
> 3. Using an application-level resolver which uses DoH/DoT to
>an application-selected resolver [as in the Firefox TRR
>system] bypasses all of these.
> 
> The key point is that a lot of filtering is broken by reasons
> that have nothing to do with encrypted transport, and so
> this text is misleading.

Somewhat confused here.. the text you quote above does not mention filtering at 
all, was added in version -04 published in January and wasn’t referenced at all 
in your first review of -04. Are you now saying you want this specific text 
reworked?

> 
> 
> > For users to have the ability to manage the DNS resolver settings for
> > each individual application in a similar fashion to the OS DNS
> > settings, each application would need to expose the default settings
> > to the user, provide a configuration interface to change them, and
> > support configuration of user specified resolvers.
> 
> This seems sort of true, though of course in some systems (I don't
> know how common this is in the world of mostly single-user computers)
> users actually can't change the system resolver settings.

We previously agreed text in section 6.1.1 that says both:

“ All major OS's expose the system DNS settings and allow users to
   manually override them if desired."

“The vast majority of users do not change their default system DNS
   settings and so implicitly accept the network settings for DNS."

Getting into user specific authorisations around this isn’t something that has 
been proposed in any comment before and I’m not sure how useful it is at this 
point?

> 
> 
> > The system resolver resolution path is sometimes used to configure
> > additional DNS controls e.g. query logging, domain based query
> > re-direction or filtering.
> 
> This conflates the network and in-OS filtering discussed above,
> which I really think needs expansion.

Suggest:

“The system resolver resolution path is sometimes used to configure additional 
device based DNS controls (distinct from any controls implemented at the 
network level) e.g. local query logging, domain based query re-direction or 
filtering."


> 
> 
> > If all of the applications used on a given device can be configured to
> > use the system resolver, such controls need only be configured on the
> > system resolver resolution path. However if applications offer neither
> > the option to use the system resolver nor equivalent
> > application-specific DNS controls then users should take note that for
> > queries generated by such an application they may not be able to
> > 
> > * directly inspect the DNS queries (e.g. if they are encrypted), or
> > 
> > * manage them to set DNS controls across the device which are
> >   consistent with the system resolver controls.
> 
> OK.
> 
> 
> > Note that if a client device is compromised by a malicious
> > application, the attacker can use application-specific DNS resolvers,
> > transport and controls of its own choosing. »
> 
> This seems opaque. Why not say "then any DNS-based controls may be
> ineffective.”

Will add that at the end of the sentence - this text was trying to be 
consistent with the similar text you earlier proposed for the similar case in 
section 6.2.1. “ In addition, if the 

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Rescorla]

Extensively trimming:

To be honest, this thread has gotten so long that I've lost
track of the various changes being proposed, so here's
my comments on the text as a whole.


> "An increasing number of applications are offering
> application-specific encrypted DNS resolution settings, rather than
> defaulting to using only the system resolver.  A variety of heuristics
> and resolvers are available in different applications including
> hard-coded lists of recognized DoH/DoT servers.

As I said earlier, I think this text is highly misleading.
There are at least two major loci of filtering via DNS:

1. In the operating system itself via the system resolver
   or hooks into that resolver.

2. In the network via (a) the selected resolver or (b) on-path
   filtering of the traffic to/from that resolver.

There are least three major application resolution technologies that
render one or more of these techniques ineffective:

1. Using an application-level resolver which uses the system settings
   [what Chrome currently does] bypasses (1)

2. Using an application-level resolver which uses DoH/DoT to the
   system configured resolver [what Edge and Chrome are experimenting
   with] bypasses (1) and maybe 2(b) if the network config gets out of
   sync (i.e., you don't want your system configured resolver to do
   DoH/DoT if you use network-level filtering, but it's easy to see
   how this can happen if (for instance) you just offer the the user
   the ISP resolver and they start supporting DoH/DoT

3. Using an application-level resolver which uses DoH/DoT to
   an application-selected resolver [as in the Firefox TRR
   system] bypasses all of these.

The key point is that a lot of filtering is broken by reasons
that have nothing to do with encrypted transport, and so
this text is misleading.


> For users to have the ability to manage the DNS resolver settings for
> each individual application in a similar fashion to the OS DNS
> settings, each application would need to expose the default settings
> to the user, provide a configuration interface to change them, and
> support configuration of user specified resolvers.

This seems sort of true, though of course in some systems (I don't
know how common this is in the world of mostly single-user computers)
users actually can't change the system resolver settings.


> The system resolver resolution path is sometimes used to configure
> additional DNS controls e.g. query logging, domain based query
> re-direction or filtering.

This conflates the network and in-OS filtering discussed above,
which I really think needs expansion.


> If all of the applications used on a given device can be configured to
> use the system resolver, such controls need only be configured on the
> system resolver resolution path. However if applications offer neither
> the option to use the system resolver nor equivalent
> application-specific DNS controls then users should take note that for
> queries generated by such an application they may not be able to
>
> * directly inspect the DNS queries (e.g. if they are encrypted), or
>
> * manage them to set DNS controls across the device which are
>   consistent with the system resolver controls.

OK.


> Note that if a client device is compromised by a malicious
> application, the attacker can use application-specific DNS resolvers,
> transport and controls of its own choosing. »

This seems opaque. Why not say "then any DNS-based controls may be
ineffective."

-Ekr
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Vyncke (evyncke)]

Eric / Ekr,

Sara has posted a revised I-D, does it address the point in your email dated 
9th of April ?

She also replied end of April with:

“I see the confusion now, the sentence beginning ‘If not,’ was meant to refer 
to whether (if they didn’t support using the system resolver) individual 
applications offered per-application settings to inspect/manage the DNS queries 
e.g. export session keys. To try to rework the text in context:

"An increasing number of applications are offering application-specific 
encrypted DNS resolution settings, rather than defaulting to using only the 
system resolver.  A variety of heuristics and resolvers are available in 
different applications including hard-coded lists of recognized DoH/DoT servers.

For users to have the ability to manage the DNS resolver settings for each 
individual application in a similar fashion to the OS DNS settings, each 
application would need to expose the default settings to the user, provide a 
configuration interface to change them, and support configuration of user 
specified resolvers.

The system resolver resolution path is sometimes used to configure additional 
DNS controls e.g. query logging, domain based query re-direction or filtering.
If all of the applications used on a given device can be configured to use the 
system resolver, such controls need only be configured on the system resolver 
resolution path. However if applications offer neither the option to use the 
system resolver nor equivalent application-specific DNS controls then users 
should take note that for queries generated by such an application they may not 
be able to
* directly inspect the DNS queries (e.g. if they are encrypted), or
* manage them to set DNS controls across the device which are consistent with 
the system resolver controls.

Note that if a client device is compromised by a malicious application, the 
attacker can use application-specific DNS resolvers, transport and controls of 
its own choosing. »


Thank you for your prompt reply

-éric V (the other one)

From: Eric Rescorla 
Date: Thursday, 9 April 2020 at 16:35
To: Sara Dickinson 
Cc: Eric Orth , "dns-privacy@ietf.org" 
, Vittorio Bertola , 
"dprive-cha...@ietf.org" , Eric Vyncke 
, "draft-ietf-dprive-rfc7626-...@ietf.org" 

Subject: Re: [dns-privacy] Datatracker State Update Notice: 




On Thu, Apr 9, 2020 at 6:36 AM Sara Dickinson 
mailto:s...@sinodun.com>> wrote:



On 9 Apr 2020, at 14:24, Eric Rescorla mailto:e...@rtfm.com>> 
wrote:






How about making the last sentence a little more specific instead:

If not, then (depending on the application and transport used for DNS queries) 
users should take note that they may not be able to inspect the DNS queries 
generated by such applications, or manage them to set consistent 
application-level controls across the device for e.g. domain based query 
re-direction or filtering. “

If the feeling is that it is really needed then I would suggest text that is 
consistent with that used in section 3.5.2.1, for example:

“ In addition, if a client device is compromised by a malicious application, 
the attacker can
  use application-specific DNS resolvers, transport and settings of its own 
choosing.”

Sort of. This seems like it still buries the lede.

"Note that if a client device is compromised by a malicious application, the 
attacker can use application-specific DNS resolvers, transport and settings of 
its own choosing and thus will not be affected by these controls.”

By 'these controls’ do you mean any controls that the malicious application 
appears to offer to the user? If so, then does this capture your point:

"Note that if a client device is compromised by a malicious application, the 
attacker can use application-specific DNS resolvers, transport and settings of 
its own choosing regardless of what DNS configuration the malicious application 
may appear to offer the user (if any).”

No. My point is that the platform level DNS controls that you are trying to use 
don't work in this case.

-Ekr


Sara.
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Sara Dickinson]

Hi Ekr, 

Could you comment on the latest proposed text below? I believe this is the last 
comment to resolve from the IETF LC on this draft...

Best regards

Sara. 

> On 20 Apr 2020, at 11:41, Sara Dickinson  wrote:
> 
> 
> 
>> On 9 Apr 2020, at 15:35, Eric Rescorla > > wrote:
>> 
>> 
>> 
>> On Thu, Apr 9, 2020 at 6:36 AM Sara Dickinson > > wrote:
>> 
>> 
>>> On 9 Apr 2020, at 14:24, Eric Rescorla >> > wrote:
>>> 
>> 
>> 
>> 
 
 How about making the last sentence a little more specific instead:
 
 If not, then (depending on the application and transport used for DNS 
 queries) users should take note that they may not be able to inspect the 
 DNS queries generated by such applications, or manage them to set 
 consistent application-level controls across the device for e.g. domain 
 based query re-direction or filtering. “
>>> 
>>> If the feeling is that it is really needed then I would suggest text that 
>>> is consistent with that used in section 3.5.2.1, for example:
>>> 
>>> “ In addition, if a client device is compromised by a malicious 
>>> application, the attacker can
>>>   use application-specific DNS resolvers, transport and settings of its own 
>>> choosing.”
>>> 
>>> Sort of. This seems like it still buries the lede.
>>> 
>>> "Note that if a client device is compromised by a malicious application, 
>>> the attacker can use application-specific DNS resolvers, transport and 
>>> settings of its own choosing and thus will not be affected by these 
>>> controls.”
>> 
>> By 'these controls’ do you mean any controls that the malicious application 
>> appears to offer to the user? If so, then does this capture your point: 
>> 
>> "Note that if a client device is compromised by a malicious application, the 
>> attacker can use application-specific DNS resolvers, transport and settings 
>> of its own choosing regardless of what DNS configuration the malicious 
>> application may appear to offer the user (if any).”
>> 
>> No. My point is that the platform level DNS controls that you are trying to 
>> use don't work in this case.
> 
> I see the confusion now, the sentence beginning ‘If not,’ was meant to refer 
> to whether (if they didn’t support using the system resolver) individual 
> applications offered per-application settings to inspect/manage the DNS 
> queries e.g. export session keys. To try to rework the text in context:
> 
> "An increasing number of applications are offering application-specific 
> encrypted DNS resolution settings, rather than defaulting to using only the 
> system resolver.  A variety of heuristics and resolvers are available in 
> different applications including hard-coded lists of recognized DoH/DoT 
> servers.
> 
> For users to have the ability to manage the DNS resolver settings for each 
> individual application in a similar fashion to the OS DNS settings, each 
> application would need to expose the default settings to the user, provide a 
> configuration interface to change them, and support configuration of user 
> specified resolvers.  
> 
> The system resolver resolution path is sometimes used to configure additional 
> DNS controls e.g. query logging, domain based query re-direction or 
> filtering. 
> If all of the applications used on a given device can be configured to use 
> the system resolver, such controls need only be configured on the system 
> resolver resolution path. However if applications offer neither the option to 
> use the system resolver nor equivalent application-specific DNS controls then 
> users should take note that for queries generated by such an application they 
> may not be able to
> * directly inspect the DNS queries (e.g. if they are encrypted), or 
> * manage them to set DNS controls across the device which are consistent with 
> the system resolver controls. 
> 
> Note that if a client device is compromised by a malicious application, the 
> attacker can use application-specific DNS resolvers, transport and controls 
> of its own choosing.“
> 
> Sara. 
> 
>> 
>> -Ekr
>> 
>> 
>> Sara. 
> 

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Sara Dickinson]

> On 9 Apr 2020, at 15:35, Eric Rescorla  wrote:
> 
> 
> 
> On Thu, Apr 9, 2020 at 6:36 AM Sara Dickinson  > wrote:
> 
> 
>> On 9 Apr 2020, at 14:24, Eric Rescorla > > wrote:
>> 
> 
> 
> 
>>> 
>>> How about making the last sentence a little more specific instead:
>>> 
>>> If not, then (depending on the application and transport used for DNS 
>>> queries) users should take note that they may not be able to inspect the 
>>> DNS queries generated by such applications, or manage them to set 
>>> consistent application-level controls across the device for e.g. domain 
>>> based query re-direction or filtering. “
>> 
>> If the feeling is that it is really needed then I would suggest text that is 
>> consistent with that used in section 3.5.2.1, for example:
>> 
>> “ In addition, if a client device is compromised by a malicious application, 
>> the attacker can
>>   use application-specific DNS resolvers, transport and settings of its own 
>> choosing.”
>> 
>> Sort of. This seems like it still buries the lede.
>> 
>> "Note that if a client device is compromised by a malicious application, the 
>> attacker can use application-specific DNS resolvers, transport and settings 
>> of its own choosing and thus will not be affected by these controls.”
> 
> By 'these controls’ do you mean any controls that the malicious application 
> appears to offer to the user? If so, then does this capture your point: 
> 
> "Note that if a client device is compromised by a malicious application, the 
> attacker can use application-specific DNS resolvers, transport and settings 
> of its own choosing regardless of what DNS configuration the malicious 
> application may appear to offer the user (if any).”
> 
> No. My point is that the platform level DNS controls that you are trying to 
> use don't work in this case.

I see the confusion now, the sentence beginning ‘If not,’ was meant to refer to 
whether (if they didn’t support using the system resolver) individual 
applications offered per-application settings to inspect/manage the DNS queries 
e.g. export session keys. To try to rework the text in context:

"An increasing number of applications are offering application-specific 
encrypted DNS resolution settings, rather than defaulting to using only the 
system resolver.  A variety of heuristics and resolvers are available in 
different applications including hard-coded lists of recognized DoH/DoT servers.

For users to have the ability to manage the DNS resolver settings for each 
individual application in a similar fashion to the OS DNS settings, each 
application would need to expose the default settings to the user, provide a 
configuration interface to change them, and support configuration of user 
specified resolvers.  

The system resolver resolution path is sometimes used to configure additional 
DNS controls e.g. query logging, domain based query re-direction or filtering. 
If all of the applications used on a given device can be configured to use the 
system resolver, such controls need only be configured on the system resolver 
resolution path. However if applications offer neither the option to use the 
system resolver nor equivalent application-specific DNS controls then users 
should take note that for queries generated by such an application they may not 
be able to
* directly inspect the DNS queries (e.g. if they are encrypted), or 
* manage them to set DNS controls across the device which are consistent with 
the system resolver controls. 

Note that if a client device is compromised by a malicious application, the 
attacker can use application-specific DNS resolvers, transport and controls of 
its own choosing.“

Sara. 

> 
> -Ekr
> 
> 
> Sara. 

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Rescorla]

On Thu, Apr 9, 2020 at 6:36 AM Sara Dickinson  wrote:

>
>
> On 9 Apr 2020, at 14:24, Eric Rescorla  wrote:
>
>
> 
>
>
>>> How about making the last sentence a little more specific instead:
>>>
>>> If not, then (depending on the application and transport used for DNS
>>> queries) users should take note that they may not be able to inspect the
>>> DNS queries generated by such applications, or manage them to set
>>> consistent application-level controls across the device for e.g. domain
>>> based query re-direction or filtering. “
>>>
>>
>> If the feeling is that it is really needed then I would suggest text that
>> is consistent with that used in section 3.5.2.1, for example:
>>
>> “ In addition, if a client device is compromised by a malicious
>> application, the attacker can
>>   use application-specific DNS resolvers, transport and settings of its
>> own choosing.”
>>
>
> Sort of. This seems like it still buries the lede.
>
> "Note that if a client device is compromised by a malicious application,
> the attacker can use application-specific DNS resolvers, transport and
> settings of its own choosing and thus will not be affected by these
> controls.”
>
>
> By 'these controls’ do you mean any controls that the malicious
> application appears to offer to the user? If so, then does this capture
> your point:
>
> "Note that if a client device is compromised by a malicious application,
> the attacker can use application-specific DNS resolvers, transport and
> settings of its own choosing regardless of what DNS configuration the
> malicious application may appear to offer the user (if any).”
>

No. My point is that the platform level DNS controls that you are trying to
use don't work in this case.

-Ekr


> Sara.
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Sara Dickinson]

> On 9 Apr 2020, at 14:24, Eric Rescorla  wrote:
> 



>> 
>> How about making the last sentence a little more specific instead:
>> 
>> If not, then (depending on the application and transport used for DNS 
>> queries) users should take note that they may not be able to inspect the DNS 
>> queries generated by such applications, or manage them to set consistent 
>> application-level controls across the device for e.g. domain based query 
>> re-direction or filtering. “
> 
> If the feeling is that it is really needed then I would suggest text that is 
> consistent with that used in section 3.5.2.1, for example:
> 
> “ In addition, if a client device is compromised by a malicious application, 
> the attacker can
>   use application-specific DNS resolvers, transport and settings of its own 
> choosing.”
> 
> Sort of. This seems like it still buries the lede.
> 
> "Note that if a client device is compromised by a malicious application, the 
> attacker can use application-specific DNS resolvers, transport and settings 
> of its own choosing and thus will not be affected by these controls.”

By 'these controls’ do you mean any controls that the malicious application 
appears to offer to the user? If so, then does this capture your point: 

"Note that if a client device is compromised by a malicious application, the 
attacker can use application-specific DNS resolvers, transport and settings of 
its own choosing regardless of what DNS configuration the malicious application 
may appear to offer the user (if any).”

Sara. ___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Rescorla]

On Thu, Apr 9, 2020 at 4:00 AM Sara Dickinson  wrote:

>
>
> On 7 Apr 2020, at 17:22, Eric Orth  wrote:
>
> "consistent application-level controls across the device"
>
> Right there is where followers of the misunderstanding will read this text
> incorrectly.  Browsers and other non-malicious applications allowing
> control does not guarantee consistent application control.
>
> On Tue, Apr 7, 2020 at 12:13 PM Sara Dickinson  wrote:
>
>>
>>
>> On 7 Apr 2020, at 16:47, Eric Rescorla  wrote:
>>
>>
>>
>> On Tue, Apr 7, 2020 at 8:40 AM Vittorio Bertola <
>> vittorio.bert...@open-xchange.com> wrote:
>>
>>>
>>> Il 07/04/2020 17:23 Eric Rescorla  ha scritto:
>>>
>>>
>>>
>>> On Tue, Apr 7, 2020 at 7:38 AM Sara Dickinson < s...@sinodun.com>
>>> wrote:
>>>
>>> The goal of this text is to enumerate for the end user the privacy
>>> considerations of using such an application so I propose this text:
>>>
>>> "For users to have the ability to manage the application-specific DNS
>>> settings in a similar fashion to the OS DNS settings, each application also
>>> needs to expose the default settings to the user, provide a configuration
>>> interface to change them, and support configuration of user specified
>>> resolvers.
>>>
>>> If all of the applications used on a given device also provide a setting
>>> to use the system resolver, then the device can be reverted to a single
>>> point of control for all DNS queries. If not, then (depending on the
>>> application and transport used for DNS queries) users should take note that
>>> they may not be able to inspect all their DNS queries or manage them to set
>>> device wide controls e.g. domain based query re-direction or filtering. “
>>>
>>>
>>> I don't think this addresses my concern, because "revert" implies that
>>> this is somehow the default situation, which, as I said, is not clearly the
>>> case because applications have been doing their own resolution for some
>>> time.
>>>
>>> In the interest of moving forward, i suggest you change the term
>>> "reverted" to "configured" and add at the end "Note that this does not
>>> guarantee controlling malware name resolution as it can simply ignore
>>> whatever the system resolver and any user configuration settings.."
>>>
>>> I don't understand where in the proposed text there was a reference to
>>> malware that prompted further discussion of the effectiveness of using DNS
>>> to counter it. In any case, if we think that we need to discuss this topic
>>> at that point in the draft, one should also note that there also are ways
>>> to prevent malware from reaching a different resolver, though they are less
>>> likely to work once connections are encrypted, etc. But I think that this
>>> would make reaching consensus even harder, so perhaps we could avoid doing
>>> so and just focus on suggestions related to application configuration.
>>>
>>
>> Well, I would be happy to strike this text entirely. However, the text
>> speaks of "control" and if we're going to say that, we should acknowledge
>> that the system DNS is not going to let you control malicious applications
>> because malware can just do its own resolution. As it is, I think the text
>> gives a false impression
>>
>>
>> How about making the last sentence a little more specific instead:
>>
>> If not, then (depending on the application and transport used for DNS
>> queries) users should take note that they may not be able to inspect the
>> DNS queries generated by such applications, or manage them to set
>> consistent application-level controls across the device for e.g. domain
>> based query re-direction or filtering. “
>>
>
> If the feeling is that it is really needed then I would suggest text that
> is consistent with that used in section 3.5.2.1, for example:
>
> “ In addition, if a client device is compromised by a malicious
> application, the attacker can
>   use application-specific DNS resolvers, transport and settings of its
> own choosing.”
>

Sort of. This seems like it still buries the lede.

"Note that if a client device is compromised by a malicious application,
the attacker can use application-specific DNS resolvers, transport and
settings of its own choosing and thus will not be affected by these
controls."


> Sara.
>
>
>
>> Sara.
>>
>>
>> -Ekr
>>
>> --
>>>
>>> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
>>> vittorio.bert...@open-xchange.com
>>> Office @ Via Treviso 12, 10144 Torino, Italy
>>>
>>>
>> ___
>> dns-privacy mailing list
>> dns-privacy@ietf.org
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
>
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Sara Dickinson]

> On 7 Apr 2020, at 17:22, Eric Orth  wrote:
> 
> "consistent application-level controls across the device"
> 
> Right there is where followers of the misunderstanding will read this text 
> incorrectly.  Browsers and other non-malicious applications allowing control 
> does not guarantee consistent application control.
> 
> On Tue, Apr 7, 2020 at 12:13 PM Sara Dickinson  > wrote:
> 
> 
>> On 7 Apr 2020, at 16:47, Eric Rescorla > > wrote:
>> 
>> 
>> 
>> On Tue, Apr 7, 2020 at 8:40 AM Vittorio Bertola 
>> > > wrote:
>> 
>>> Il 07/04/2020 17:23 Eric Rescorla mailto:e...@rtfm.com>> ha 
>>> scritto:
>>> 
>>> 
>>> 
>>> On Tue, Apr 7, 2020 at 7:38 AM Sara Dickinson < s...@sinodun.com 
>>> > wrote: 
>>> The goal of this text is to enumerate for the end user the privacy 
>>> considerations of using such an application so I propose this text: 
>>> 
>>> "For users to have the ability to manage the application-specific DNS 
>>> settings in a similar fashion to the OS DNS settings, each application also 
>>> needs to expose the default settings to the user, provide a configuration 
>>> interface to change them, and support configuration of user specified 
>>> resolvers.  
>>> 
>>> If all of the applications used on a given device also provide a setting to 
>>> use the system resolver, then the device can be reverted to a single point 
>>> of control for all DNS queries. If not, then (depending on the application 
>>> and transport used for DNS queries) users should take note that they may 
>>> not be able to inspect all their DNS queries or manage them to set device 
>>> wide controls e.g. domain based query re-direction or filtering. “
>>> 
>>> I don't think this addresses my concern, because "revert" implies that this 
>>> is somehow the default situation, which, as I said, is not clearly the case 
>>> because applications have been doing their own resolution for some time.
>>> 
>>> In the interest of moving forward, i suggest you change the term "reverted" 
>>> to "configured" and add at the end "Note that this does not guarantee 
>>> controlling malware name resolution as it can simply ignore whatever the 
>>> system resolver and any user configuration settings.."
>> I don't understand where in the proposed text there was a reference to 
>> malware that prompted further discussion of the effectiveness of using DNS 
>> to counter it. In any case, if we think that we need to discuss this topic 
>> at that point in the draft, one should also note that there also are ways to 
>> prevent malware from reaching a different resolver, though they are less 
>> likely to work once connections are encrypted, etc. But I think that this 
>> would make reaching consensus even harder, so perhaps we could avoid doing 
>> so and just focus on suggestions related to application configuration.
>> 
>> Well, I would be happy to strike this text entirely. However, the text 
>> speaks of "control" and if we're going to say that, we should acknowledge 
>> that the system DNS is not going to let you control malicious applications 
>> because malware can just do its own resolution. As it is, I think the text 
>> gives a false impression 
> 
> How about making the last sentence a little more specific instead:
> 
> If not, then (depending on the application and transport used for DNS 
> queries) users should take note that they may not be able to inspect the DNS 
> queries generated by such applications, or manage them to set consistent 
> application-level controls across the device for e.g. domain based query 
> re-direction or filtering. “

If the feeling is that it is really needed then I would suggest text that is 
consistent with that used in section 3.5.2.1, for example:

“ In addition, if a client device is compromised by a malicious application, 
the attacker can
  use application-specific DNS resolvers, transport and settings of its own 
choosing.”

Sara. 


> 
> Sara. 
> 
>> 
>> -Ekr
>> 
>> -- 
>> 
>> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
>> vittorio.bert...@open-xchange.com  
>> Office @ Via Treviso 12, 10144 Torino, Italy
> 
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org 
> https://www.ietf.org/mailman/listinfo/dns-privacy 
> 

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Orth]

"consistent application-level controls across the device"

Right there is where followers of the misunderstanding will read this text
incorrectly.  Browsers and other non-malicious applications allowing
control does not guarantee consistent application control.

On Tue, Apr 7, 2020 at 12:13 PM Sara Dickinson  wrote:

>
>
> On 7 Apr 2020, at 16:47, Eric Rescorla  wrote:
>
>
>
> On Tue, Apr 7, 2020 at 8:40 AM Vittorio Bertola <
> vittorio.bert...@open-xchange.com> wrote:
>
>>
>> Il 07/04/2020 17:23 Eric Rescorla  ha scritto:
>>
>>
>>
>> On Tue, Apr 7, 2020 at 7:38 AM Sara Dickinson < s...@sinodun.com> wrote:
>>
>> The goal of this text is to enumerate for the end user the privacy
>> considerations of using such an application so I propose this text:
>>
>> "For users to have the ability to manage the application-specific DNS
>> settings in a similar fashion to the OS DNS settings, each application also
>> needs to expose the default settings to the user, provide a configuration
>> interface to change them, and support configuration of user specified
>> resolvers.
>>
>> If all of the applications used on a given device also provide a setting
>> to use the system resolver, then the device can be reverted to a single
>> point of control for all DNS queries. If not, then (depending on the
>> application and transport used for DNS queries) users should take note that
>> they may not be able to inspect all their DNS queries or manage them to set
>> device wide controls e.g. domain based query re-direction or filtering. “
>>
>>
>> I don't think this addresses my concern, because "revert" implies that
>> this is somehow the default situation, which, as I said, is not clearly the
>> case because applications have been doing their own resolution for some
>> time.
>>
>> In the interest of moving forward, i suggest you change the term
>> "reverted" to "configured" and add at the end "Note that this does not
>> guarantee controlling malware name resolution as it can simply ignore
>> whatever the system resolver and any user configuration settings.."
>>
>> I don't understand where in the proposed text there was a reference to
>> malware that prompted further discussion of the effectiveness of using DNS
>> to counter it. In any case, if we think that we need to discuss this topic
>> at that point in the draft, one should also note that there also are ways
>> to prevent malware from reaching a different resolver, though they are less
>> likely to work once connections are encrypted, etc. But I think that this
>> would make reaching consensus even harder, so perhaps we could avoid doing
>> so and just focus on suggestions related to application configuration.
>>
>
> Well, I would be happy to strike this text entirely. However, the text
> speaks of "control" and if we're going to say that, we should acknowledge
> that the system DNS is not going to let you control malicious applications
> because malware can just do its own resolution. As it is, I think the text
> gives a false impression
>
>
> How about making the last sentence a little more specific instead:
>
> If not, then (depending on the application and transport used for DNS
> queries) users should take note that they may not be able to inspect the
> DNS queries generated by such applications, or manage them to set
> consistent application-level controls across the device for e.g. domain
> based query re-direction or filtering. “
>
> Sara.
>
>
> -Ekr
>
> --
>>
>> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
>> vittorio.bert...@open-xchange.com
>> Office @ Via Treviso 12, 10144 Torino, Italy
>>
>>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Sara Dickinson]

> On 7 Apr 2020, at 16:47, Eric Rescorla  wrote:
> 
> 
> 
> On Tue, Apr 7, 2020 at 8:40 AM Vittorio Bertola 
>  > wrote:
> 
>> Il 07/04/2020 17:23 Eric Rescorla mailto:e...@rtfm.com>> ha 
>> scritto:
>> 
>> 
>> 
>> On Tue, Apr 7, 2020 at 7:38 AM Sara Dickinson < s...@sinodun.com 
>> > wrote: 
>> The goal of this text is to enumerate for the end user the privacy 
>> considerations of using such an application so I propose this text: 
>> 
>> "For users to have the ability to manage the application-specific DNS 
>> settings in a similar fashion to the OS DNS settings, each application also 
>> needs to expose the default settings to the user, provide a configuration 
>> interface to change them, and support configuration of user specified 
>> resolvers.  
>> 
>> If all of the applications used on a given device also provide a setting to 
>> use the system resolver, then the device can be reverted to a single point 
>> of control for all DNS queries. If not, then (depending on the application 
>> and transport used for DNS queries) users should take note that they may not 
>> be able to inspect all their DNS queries or manage them to set device wide 
>> controls e.g. domain based query re-direction or filtering. “
>> 
>> I don't think this addresses my concern, because "revert" implies that this 
>> is somehow the default situation, which, as I said, is not clearly the case 
>> because applications have been doing their own resolution for some time.
>> 
>> In the interest of moving forward, i suggest you change the term "reverted" 
>> to "configured" and add at the end "Note that this does not guarantee 
>> controlling malware name resolution as it can simply ignore whatever the 
>> system resolver and any user configuration settings.."
> I don't understand where in the proposed text there was a reference to 
> malware that prompted further discussion of the effectiveness of using DNS to 
> counter it. In any case, if we think that we need to discuss this topic at 
> that point in the draft, one should also note that there also are ways to 
> prevent malware from reaching a different resolver, though they are less 
> likely to work once connections are encrypted, etc. But I think that this 
> would make reaching consensus even harder, so perhaps we could avoid doing so 
> and just focus on suggestions related to application configuration.
> 
> Well, I would be happy to strike this text entirely. However, the text speaks 
> of "control" and if we're going to say that, we should acknowledge that the 
> system DNS is not going to let you control malicious applications because 
> malware can just do its own resolution. As it is, I think the text gives a 
> false impression 

How about making the last sentence a little more specific instead:

If not, then (depending on the application and transport used for DNS queries) 
users should take note that they may not be able to inspect the DNS queries 
generated by such applications, or manage them to set consistent 
application-level controls across the device for e.g. domain based query 
re-direction or filtering. “

Sara. 

> 
> -Ekr
> 
> -- 
> 
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> vittorio.bert...@open-xchange.com  
> Office @ Via Treviso 12, 10144 Torino, Italy

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Orth]

It is currently a very common* misunderstanding that system or
browser/application DNS configuration can somehow control malware
resolution.  Common enough that, IMO, any text on how to "control" or
configure resolution or "disable" features like DoH should include at least
a small clarification on the point of the scope/limitations of that
configuration.

*Anecdotal evidence is the large number of times I have been asked for
guidance on "stopping malware" through disabling Chrome DoH.  I always have
to give the reminder that I can only help with controlling resolutions
which go through Chrome, which malware will often not do.
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Rescorla]

On Tue, Apr 7, 2020 at 8:40 AM Vittorio Bertola <
vittorio.bert...@open-xchange.com> wrote:

>
> Il 07/04/2020 17:23 Eric Rescorla  ha scritto:
>
>
>
> On Tue, Apr 7, 2020 at 7:38 AM Sara Dickinson < s...@sinodun.com> wrote:
>
> The goal of this text is to enumerate for the end user the privacy
> considerations of using such an application so I propose this text:
>
> "For users to have the ability to manage the application-specific DNS
> settings in a similar fashion to the OS DNS settings, each application also
> needs to expose the default settings to the user, provide a configuration
> interface to change them, and support configuration of user specified
> resolvers.
>
> If all of the applications used on a given device also provide a setting
> to use the system resolver, then the device can be reverted to a single
> point of control for all DNS queries. If not, then (depending on the
> application and transport used for DNS queries) users should take note that
> they may not be able to inspect all their DNS queries or manage them to set
> device wide controls e.g. domain based query re-direction or filtering. “
>
>
> I don't think this addresses my concern, because "revert" implies that
> this is somehow the default situation, which, as I said, is not clearly the
> case because applications have been doing their own resolution for some
> time.
>
> In the interest of moving forward, i suggest you change the term
> "reverted" to "configured" and add at the end "Note that this does not
> guarantee controlling malware name resolution as it can simply ignore
> whatever the system resolver and any user configuration settings.."
>
> I don't understand where in the proposed text there was a reference to
> malware that prompted further discussion of the effectiveness of using DNS
> to counter it. In any case, if we think that we need to discuss this topic
> at that point in the draft, one should also note that there also are ways
> to prevent malware from reaching a different resolver, though they are less
> likely to work once connections are encrypted, etc. But I think that this
> would make reaching consensus even harder, so perhaps we could avoid doing
> so and just focus on suggestions related to application configuration.
>

Well, I would be happy to strike this text entirely. However, the text
speaks of "control" and if we're going to say that, we should acknowledge
that the system DNS is not going to let you control malicious applications
because malware can just do its own resolution. As it is, I think the text
gives a false impression

-Ekr

-- 
>
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> vittorio.bert...@open-xchange.com
> Office @ Via Treviso 12, 10144 Torino, Italy
>
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Vittorio Bertola]

> Il 07/04/2020 17:23 Eric Rescorla  ha scritto:
> 
> 
> 
> On Tue, Apr 7, 2020 at 7:38 AM Sara Dickinson < s...@sinodun.com 
> mailto:s...@sinodun.com > wrote:
> 
> > > The goal of this text is to enumerate for the end user 
> the privacy considerations of using such an application so I propose this 
> text:
> > 
> > "For users to have the ability to manage the application-specific 
> > DNS settings in a similar fashion to the OS DNS settings, each application 
> > also needs to expose the default settings to the user, provide a 
> > configuration interface to change them, and support configuration of user 
> > specified resolvers.  
> > 
> > If all of the applications used on a given device also provide a 
> > setting to use the system resolver, then the device can be reverted to a 
> > single point of control for all DNS queries. If not, then (depending on the 
> > application and transport used for DNS queries) users should take note that 
> > they may not be able to inspect all their DNS queries or manage them to set 
> > device wide controls e.g. domain based query re-direction or filtering. “
> > 
> > > 
> I don't think this addresses my concern, because "revert" implies that 
> this is somehow the default situation, which, as I said, is not clearly the 
> case because applications have been doing their own resolution for some time.
> 
> In the interest of moving forward, i suggest you change the term 
> "reverted" to "configured" and add at the end "Note that this does not 
> guarantee controlling malware name resolution as it can simply ignore 
> whatever the system resolver and any user configuration settings.."
> 
I don't understand where in the proposed text there was a reference to malware 
that prompted further discussion of the effectiveness of using DNS to counter 
it. In any case, if we think that we need to discuss this topic at that point 
in the draft, one should also note that there also are ways to prevent malware 
from reaching a different resolver, though they are less likely to work once 
connections are encrypted, etc. But I think that this would make reaching 
consensus even harder, so perhaps we could avoid doing so and just focus on 
suggestions related to application configuration.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Rescorla]

On Tue, Apr 7, 2020 at 7:38 AM Sara Dickinson  wrote:

>
>
> Begin forwarded message:
>
> *From: *Eric Rescorla 
> *Subject: **Re: [dns-privacy] Datatracker State Update Notice:
> *
> *Date: *9 March 2020 at 15:01:09 GMT
> *To: *Sara Dickinson 
> *Cc: *Brian Dickson , "Eric Vyncke
> (evyncke)" , "dprive-cha...@ietf.org" <
> dprive-cha...@ietf.org>, "dns-privacy@ietf.org" , "
> draft-ietf-dprive-rfc7626-...@ietf.org" <
> draft-ietf-dprive-rfc7626-...@ietf.org>
>
>
>
> On Mon, Mar 9, 2020 at 3:55 AM Sara Dickinson  wrote:
>
>
> Reviewing this thread after several weeks I realised we had one final
> comment to still resolve so trimming the reponse to focus on that….
>
> 
>
>
>>>>>
>>>>> The vast majority of users do not change default application-specific
>>>>>> settings and so implicitly accept the application-specific settings for
>>>>>> DNS. As with network resolvers, these resolvers may have strong, medium, 
>>>>>> or
>>>>>> weak privacy policies depending on the application.  Privacy policies for
>>>>>> these servers may or may not be available and users need to be aware that
>>>>>> privacy guarantees will vary with each application.
>>>>>>
>>>>>> For users to have the ability to inspect and control the
>>>>>> application-specific DNS settings in a similar fashion to the OS DNS
>>>>>> settings, each application must also:
>>>>>>
>>>>>>o  expose the default settings to the user
>>>>>>
>>>>>>o  provide configuration options to manually override the default
>>>>>> settings
>>>>>>
>>>>>>o  provide configuration options to always use the system resolver"
>>>>>>
>>>>>
>>>>> This last point is wrong. The parallel here would be to use the
>>>>> *network provided* resolver, not the system resolver. I would suggest that
>>>>> you be less prescriptive about this and just say "applications will need 
>>>>> to
>>>>> provide user-visible options to configure the resolver." I would avoid
>>>>> "must" (even in lower case) because this is a statement of fact, not a
>>>>> normative one.
>>>>>
>>>>
>>>
>>>> No, system resolver is accurate. In addition to not knowing what
>>>> possible resolver is offered by DHCP, the application can't know if DHCP
>>>> (i.e. network provided) is even being used -- the system could be using a
>>>> static choice of resolver, or even other non-DNS resolution services (e.g.
>>>> NIS+).
>>>>
>>>
>>> It turns out that there are at least three options here:
>>>
>>> - Select your own resolver
>>> - Select the resolver *configured into the system* (AIUI this is what
>>> Chrome does).
>>> - Use the system resolver via the conventional API calls.
>>>
>>>
>>> Suggest:
>>>
>>> "For users to have the ability to inspect and control the
>>> application-specific DNS settings in a similar fashion to the OS DNS
>>> settings, each application also needs to:
>>>
>>>o  expose the default settings to the user
>>>
>>>o  provide configuration options to manually override the default
>>> settings so that resolution is performed via
>>>   * user specified resolvers
>>>   * the resolvers configured into the system settings
>>>   * the system resolver via conventional API calls
>>>
>>> If all such applications are updated to use the system resolver, as
>>> described in the last bullet point, the device reverts to a single point of
>>> control for all DNS queries."
>>>
>>
>> Hmm this seems unduly prescriptive. Perhaps.
>>
>> For users to have the ability to inspect and control the
>> application-specific DNS settings in a similar fashion to the OS DNS
>> settings, each application also needs to expose the default settings
>> to the users and provide a configuration interface to change them.  If
>> this interface includes a setting to use the system resolver, then the
>> device can be reverted to a single point of control for all DNS
>> queries.
>>
>>
>> I think this removes the status quo bias.
>>
>>
>> 

Re: [dns-privacy] Datatracker State Update Notice:

[Sara Dickinson]

> Begin forwarded message:
> 
> From: Eric Rescorla 
> Subject: Re: [dns-privacy] Datatracker State Update Notice: 
> 
> Date: 9 March 2020 at 15:01:09 GMT
> To: Sara Dickinson 
> Cc: Brian Dickson , "Eric Vyncke (evyncke)" 
> , "dprive-cha...@ietf.org" , 
> "dns-privacy@ietf.org" , 
> "draft-ietf-dprive-rfc7626-...@ietf.org" 
> 
> 
> 
> 
> On Mon, Mar 9, 2020 at 3:55 AM Sara Dickinson  <mailto:s...@sinodun.com>> wrote:

Reviewing this thread after several weeks I realised we had one final comment 
to still resolve so trimming the reponse to focus on that…..



>>> 
>>> 
>>> The vast majority of users do not change default application-specific 
>>> settings and so implicitly accept the application-specific settings for 
>>> DNS. As with network resolvers, these resolvers may have strong, medium, or 
>>> weak privacy policies depending on the application.  Privacy policies for 
>>> these servers may or may not be available and users need to be aware that 
>>> privacy guarantees will vary with each application. 
>>> 
>>> For users to have the ability to inspect and control the 
>>> application-specific DNS settings in a similar fashion to the OS DNS 
>>> settings, each application must also:
>>> 
>>>o  expose the default settings to the user
>>> 
>>>o  provide configuration options to manually override the default 
>>> settings
>>> 
>>>o  provide configuration options to always use the system resolver"
>>> 
>>> This last point is wrong. The parallel here would be to use the *network 
>>> provided* resolver, not the system resolver. I would suggest that you be 
>>> less prescriptive about this and just say "applications will need to 
>>> provide user-visible options to configure the resolver." I would avoid 
>>> "must" (even in lower case) because this is a statement of fact, not a 
>>> normative one.
>> 
>>> 
>>> No, system resolver is accurate. In addition to not knowing what possible 
>>> resolver is offered by DHCP, the application can't know if DHCP (i.e. 
>>> network provided) is even being used -- the system could be using a static 
>>> choice of resolver, or even other non-DNS resolution services (e.g. NIS+).
>>> 
>>> It turns out that there are at least three options here:
>>> 
>>> - Select your own resolver
>>> - Select the resolver *configured into the system* (AIUI this is what 
>>> Chrome does).
>>> - Use the system resolver via the conventional API calls.
>> 
>> Suggest: 
>> 
>> "For users to have the ability to inspect and control the 
>> application-specific DNS settings in a similar fashion to the OS DNS 
>> settings, each application also needs to:
>> 
>>o  expose the default settings to the user
>> 
>>o  provide configuration options to manually override the default 
>> settings so that resolution is performed via
>>   * user specified resolvers
>>   * the resolvers configured into the system settings
>>   * the system resolver via conventional API calls
>> 
>> If all such applications are updated to use the system resolver, as 
>> described in the last bullet point, the device reverts to a single point of 
>> control for all DNS queries."
>> 
>> Hmm this seems unduly prescriptive. Perhaps.
>> 
>> For users to have the ability to inspect and control the
>> application-specific DNS settings in a similar fashion to the OS DNS
>> settings, each application also needs to expose the default settings
>> to the users and provide a configuration interface to change them.  If
>> this interface includes a setting to use the system resolver, then the
>> device can be reverted to a single point of control for all DNS
>> queries.
>> 
>> I think this removes the status quo bias. 
> 
> I’d be OK with removing the sub-second bullet point but I think the other two 
> have specific existing use cases:
> 
> - ‘change them’ doesn’t explicitly allow for user specified resolvers which 
> all OS’s do
> - without the option to disable the application-specific resolution a user 
> cannot apply device level controls to their DNS queries (logging, filtering 
> or rules directing different queries to different resolvers) in a way that 
> can be done today. 
> 
> But this is what I mean by "status quo bias". And in this case, I suspect 
> it's not even corr

Re: [dns-privacy] Datatracker State Update Notice:

[Tony Finch]

Jim Reid  wrote:

> Could the people on this thread *please* trim their postings?

Yes, more RFC 1855, please!

Tony.
-- 
   .-_|\f.anthony.n.finch
  / \  
McQuary ->*.--._/http://dotat.at/
   v

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Rescorla]

On Mon, Mar 9, 2020 at 2:14 PM Brian Dickson 
wrote:

>
>
> On Mon, Mar 9, 2020 at 1:14 PM Eric Rescorla  wrote:
>
>>
>> As I said, Chrome does its own name resolution and has for quite some
>> time, using the resolvers configured into the system and then sending its
>> own DNS packets. This used to be common practice in SIP softphones, but I
>> haven't worked on one in quite some time.  I'm not sure on what basis you
>> claim iOS doesn't support this, as that's not my understanding. Can you
>> provide a citation here?
>>
>
> Sure.
>
> From
> https://developer.apple.com/documentation/networkextension/dns_proxy_provider
>
> DNS proxy providers are only supported on supervised iOS devices.
>
>
> (And the latter is described here:
> https://support.apple.com/guide/apple-configurator-2/supervised-devices-apd9e4f64088/mac
>  )
>
> So basically, the ability to use third party DNS is limited to managed
> devices, corporate or education.
> The only other exception is the one done via VPN services, which is a
> different set of frameworks, IIUC.
> (That's why 1.1.1.1 is a VPN app rather than just a resolver, I believe.)
>

Ah. I think we are talking about different things:

- Yes, it seems like iOS does not officially support an app which provides
DNS services for other apps (though apparently there is an unofficial way
to do it via the VPN hooks)
- Individual apps, however, are able to do their own DNS resolution via the
obvious mechanism of sending their own UDP packets to port 53.

-Ekr
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Brian Dickson]

Hi, Jim,

I was planning on replying to you with a just-for-you trimmed version, but
your email server refuses email I send (I use gmail... I know...), but
yeah, I will in future trim the replies.
Brian

On Mon, Mar 9, 2020 at 2:19 PM Jim Reid  wrote:

> Could the people on this thread *please* trim their postings? It's hard to
> track the discussion when every email contains a jumbled set of a gazillion
> postings. Thanks.
>
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Jim Reid]

Could the people on this thread *please* trim their postings? It's hard to 
track the discussion when every email contains a jumbled set of a gazillion 
postings. Thanks.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Brian Dickson]

On Mon, Mar 9, 2020 at 1:14 PM Eric Rescorla  wrote:

>
>
> On Mon, Mar 9, 2020 at 12:18 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Mon, Mar 9, 2020 at 8:01 AM Eric Rescorla  wrote:
>>
>>>
>>>
>>> On Mon, Mar 9, 2020 at 3:55 AM Sara Dickinson  wrote:
>>>


 On 6 Mar 2020, at 13:32, Eric Rescorla  wrote:



 On Mon, Mar 2, 2020 at 7:16 AM Sara Dickinson  wrote:

>
>
> On 29 Feb 2020, at 02:03, Eric Rescorla  wrote:
>
>
>
> On Fri, Feb 28, 2020 at 4:50 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Fri, Feb 28, 2020 at 3:15 PM Eric Rescorla  wrote:
>>
>>>
>>>
>>> On Wed, Feb 26, 2020 at 6:19 AM Sara Dickinson 
>>> wrote:
>>>


 On 23 Jan 2020, at 13:53, Eric Rescorla  wrote:

 On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson 
 wrote:



 On 20 Jan 2020, at 22:37, Eric Rescorla  wrote:

 Review comments attached:


 COMMENTS
> S 3.1.
> >  described above, and may not have any confidentiality
> requirements.
> >  However, the same is not true of a single transaction or a
> sequence
> >  of transactions; that transaction is not / should not be
> public.  A
> >  typical example from outside the DNS world is: the web site
> of
> >  Alcoholics Anonymous is public; the fact that you visit it
> should not
> >  be.
>
> Well, technically what you want to conceal is the origin of the
> transaction or its linkage to other transactions. The existence of
> the
> query for that A record isn't secret.
>
>
> Suggest:
>
> “that transaction (and specifically the origin of that
> transaction) is not / should not be public."
>

 The parenthetical swallows the main sentence. The accurate thing to
 say is:

 In general, the existence of a single query is not sensitive --
 though there may be exceptions
 for some very low use domains. However, the origin of a given query
 may leak information
 about specific users and the ability to link queries reveals
 information about individual use
 patterns.


 To fit with existing text suggest:

  However, the same is not true of a single transaction or a sequence
  of transactions; those transaction are not / should not be public..
 A single
  transactions reveals both the originator of the query and the
 query
  contents which potentially leaks sensitive information about a
 specific user. A
  typical example from outside the DNS world is: the web site of
  Alcoholics Anonymous is public; the fact that you visit it should
 not
  be.

>>>
>>> I find this text a bit clumsy, but OK.
>>>
>>>
>>> Furthermore, the ability to link queries reveals information about
 individual use patterns.

>>>
>>> The key thing is "link queries as being from the same user”
>>>
>>
> OK - will include that.
>
>
>
>>>
 



>
>
>
>
> S 3.4.2.
> >  services available.  Given this, the choice of a user to
> configure a
> >  single resolver (or a fixed set of resolvers) and an
> encrypted
> >  transport to use in all network environments can actually
> serve to
> >  identify the user as one that desires privacy and can
> provide an
> >  added mechanism to track them as they move across network
> >  environments.
>
> I don't understand this paragraph. It's not the choice of specific
> resolvers that leaks data, but the choice to turn on encryption, In
> fact, from an identification purpose, the more resolvers that
> support
> encrypted transport, the better signal this is.
>
>
> This was driven by an observation that many early adopters set up
> their own DoT server and used that from all their devices, which 
> could act
> as a way to identify that user.
>

 1. This seems like an edge case.
 2. We already have plenty of people running their own unencrypted
 resolvers for other reasons.


 I can live with removing this text, but it does seem there is
 something to say about the fact configuring a single resolver for a 
 device
 could differentiate a user….

>>>
>>> Sure, but this has 

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Rescorla]

On Mon, Mar 9, 2020 at 12:18 PM Brian Dickson 
wrote:

>
>
> On Mon, Mar 9, 2020 at 8:01 AM Eric Rescorla  wrote:
>
>>
>>
>> On Mon, Mar 9, 2020 at 3:55 AM Sara Dickinson  wrote:
>>
>>>
>>>
>>> On 6 Mar 2020, at 13:32, Eric Rescorla  wrote:
>>>
>>>
>>>
>>> On Mon, Mar 2, 2020 at 7:16 AM Sara Dickinson  wrote:
>>>


 On 29 Feb 2020, at 02:03, Eric Rescorla  wrote:



 On Fri, Feb 28, 2020 at 4:50 PM Brian Dickson <
 brian.peter.dick...@gmail.com> wrote:

>
>
> On Fri, Feb 28, 2020 at 3:15 PM Eric Rescorla  wrote:
>
>>
>>
>> On Wed, Feb 26, 2020 at 6:19 AM Sara Dickinson 
>> wrote:
>>
>>>
>>>
>>> On 23 Jan 2020, at 13:53, Eric Rescorla  wrote:
>>>
>>> On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson 
>>> wrote:
>>>
>>>
>>>
>>> On 20 Jan 2020, at 22:37, Eric Rescorla  wrote:
>>>
>>> Review comments attached:
>>>
>>>
>>> COMMENTS
 S 3.1.
 >  described above, and may not have any confidentiality
 requirements.
 >  However, the same is not true of a single transaction or a
 sequence
 >  of transactions; that transaction is not / should not be
 public.  A
 >  typical example from outside the DNS world is: the web site
 of
 >  Alcoholics Anonymous is public; the fact that you visit it
 should not
 >  be.

 Well, technically what you want to conceal is the origin of the
 transaction or its linkage to other transactions. The existence of
 the
 query for that A record isn't secret.


 Suggest:

 “that transaction (and specifically the origin of that transaction)
 is not / should not be public."

>>>
>>> The parenthetical swallows the main sentence. The accurate thing to
>>> say is:
>>>
>>> In general, the existence of a single query is not sensitive --
>>> though there may be exceptions
>>> for some very low use domains. However, the origin of a given query
>>> may leak information
>>> about specific users and the ability to link queries reveals
>>> information about individual use
>>> patterns.
>>>
>>>
>>> To fit with existing text suggest:
>>>
>>>  However, the same is not true of a single transaction or a sequence
>>>  of transactions; those transaction are not / should not be public.
>>> A single
>>>  transactions reveals both the originator of the query and the query
>>>  contents which potentially leaks sensitive information about a
>>> specific user. A
>>>  typical example from outside the DNS world is: the web site of
>>>  Alcoholics Anonymous is public; the fact that you visit it should
>>> not
>>>  be.
>>>
>>
>> I find this text a bit clumsy, but OK.
>>
>>
>> Furthermore, the ability to link queries reveals information about
>>> individual use patterns.
>>>
>>
>> The key thing is "link queries as being from the same user”
>>
>
 OK - will include that.



>>
>>> 
>>>
>>>
>>>




 S 3.4.2.
 >  services available.  Given this, the choice of a user to
 configure a
 >  single resolver (or a fixed set of resolvers) and an
 encrypted
 >  transport to use in all network environments can actually
 serve to
 >  identify the user as one that desires privacy and can
 provide an
 >  added mechanism to track them as they move across network
 >  environments.

 I don't understand this paragraph. It's not the choice of specific
 resolvers that leaks data, but the choice to turn on encryption, In
 fact, from an identification purpose, the more resolvers that
 support
 encrypted transport, the better signal this is.


 This was driven by an observation that many early adopters set up
 their own DoT server and used that from all their devices, which could 
 act
 as a way to identify that user.

>>>
>>> 1. This seems like an edge case.
>>> 2. We already have plenty of people running their own unencrypted
>>> resolvers for other reasons.
>>>
>>>
>>> I can live with removing this text, but it does seem there is
>>> something to say about the fact configuring a single resolver for a 
>>> device
>>> could differentiate a user….
>>>
>>
>> Sure, but this has nothing to do with DoH or DoT.
>>
>>
> I think the text might be clearer if the bit "as one that desires
> privacy and" were removed.
> The issue isn't whether a specific user desires privacy, it is whether
> a specific user can be 

Re: [dns-privacy] Datatracker State Update Notice:

[Brian Dickson]

On Mon, Mar 9, 2020 at 8:01 AM Eric Rescorla  wrote:

>
>
> On Mon, Mar 9, 2020 at 3:55 AM Sara Dickinson  wrote:
>
>>
>>
>> On 6 Mar 2020, at 13:32, Eric Rescorla  wrote:
>>
>>
>>
>> On Mon, Mar 2, 2020 at 7:16 AM Sara Dickinson  wrote:
>>
>>>
>>>
>>> On 29 Feb 2020, at 02:03, Eric Rescorla  wrote:
>>>
>>>
>>>
>>> On Fri, Feb 28, 2020 at 4:50 PM Brian Dickson <
>>> brian.peter.dick...@gmail.com> wrote:
>>>


 On Fri, Feb 28, 2020 at 3:15 PM Eric Rescorla  wrote:

>
>
> On Wed, Feb 26, 2020 at 6:19 AM Sara Dickinson 
> wrote:
>
>>
>>
>> On 23 Jan 2020, at 13:53, Eric Rescorla  wrote:
>>
>> On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson 
>> wrote:
>>
>>
>>
>> On 20 Jan 2020, at 22:37, Eric Rescorla  wrote:
>>
>> Review comments attached:
>>
>>
>> COMMENTS
>>> S 3.1.
>>> >  described above, and may not have any confidentiality
>>> requirements.
>>> >  However, the same is not true of a single transaction or a
>>> sequence
>>> >  of transactions; that transaction is not / should not be
>>> public.  A
>>> >  typical example from outside the DNS world is: the web site of
>>> >  Alcoholics Anonymous is public; the fact that you visit it
>>> should not
>>> >  be.
>>>
>>> Well, technically what you want to conceal is the origin of the
>>> transaction or its linkage to other transactions. The existence of
>>> the
>>> query for that A record isn't secret.
>>>
>>>
>>> Suggest:
>>>
>>> “that transaction (and specifically the origin of that transaction)
>>> is not / should not be public."
>>>
>>
>> The parenthetical swallows the main sentence. The accurate thing to
>> say is:
>>
>> In general, the existence of a single query is not sensitive --
>> though there may be exceptions
>> for some very low use domains. However, the origin of a given query
>> may leak information
>> about specific users and the ability to link queries reveals
>> information about individual use
>> patterns.
>>
>>
>> To fit with existing text suggest:
>>
>>  However, the same is not true of a single transaction or a sequence
>>  of transactions; those transaction are not / should not be public. A
>> single
>>  transactions reveals both the originator of the query and the query
>>  contents which potentially leaks sensitive information about a
>> specific user. A
>>  typical example from outside the DNS world is: the web site of
>>  Alcoholics Anonymous is public; the fact that you visit it should not
>>  be.
>>
>
> I find this text a bit clumsy, but OK.
>
>
> Furthermore, the ability to link queries reveals information about
>> individual use patterns.
>>
>
> The key thing is "link queries as being from the same user”
>

>>> OK - will include that.
>>>
>>>
>>>
>
>> 
>>
>>
>>
>>>
>>>
>>>
>>>
>>> S 3.4.2.
>>> >  services available.  Given this, the choice of a user to
>>> configure a
>>> >  single resolver (or a fixed set of resolvers) and an encrypted
>>> >  transport to use in all network environments can actually
>>> serve to
>>> >  identify the user as one that desires privacy and can provide
>>> an
>>> >  added mechanism to track them as they move across network
>>> >  environments.
>>>
>>> I don't understand this paragraph. It's not the choice of specific
>>> resolvers that leaks data, but the choice to turn on encryption, In
>>> fact, from an identification purpose, the more resolvers that support
>>> encrypted transport, the better signal this is.
>>>
>>>
>>> This was driven by an observation that many early adopters set up
>>> their own DoT server and used that from all their devices, which could 
>>> act
>>> as a way to identify that user.
>>>
>>
>> 1. This seems like an edge case.
>> 2. We already have plenty of people running their own unencrypted
>> resolvers for other reasons.
>>
>>
>> I can live with removing this text, but it does seem there is
>> something to say about the fact configuring a single resolver for a 
>> device
>> could differentiate a user….
>>
>
> Sure, but this has nothing to do with DoH or DoT.
>
>
 I think the text might be clearer if the bit "as one that desires
 privacy and" were removed.
 The issue isn't whether a specific user desires privacy, it is whether
 a specific user can be identified and tracked.

 This RFC update, is about privacy.
 This particular section is on encrypted transport.
 This paragraph is highlighting that configuring a static list of
 resolvers, even if those use encrypted transport, may expose 

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Rescorla]

On Mon, Mar 9, 2020 at 3:55 AM Sara Dickinson  wrote:

>
>
> On 6 Mar 2020, at 13:32, Eric Rescorla  wrote:
>
>
>
> On Mon, Mar 2, 2020 at 7:16 AM Sara Dickinson  wrote:
>
>>
>>
>> On 29 Feb 2020, at 02:03, Eric Rescorla  wrote:
>>
>>
>>
>> On Fri, Feb 28, 2020 at 4:50 PM Brian Dickson <
>> brian.peter.dick...@gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, Feb 28, 2020 at 3:15 PM Eric Rescorla  wrote:
>>>


 On Wed, Feb 26, 2020 at 6:19 AM Sara Dickinson 
 wrote:

>
>
> On 23 Jan 2020, at 13:53, Eric Rescorla  wrote:
>
> On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson 
> wrote:
>
>
>
> On 20 Jan 2020, at 22:37, Eric Rescorla  wrote:
>
> Review comments attached:
>
>
> COMMENTS
>> S 3.1.
>> >  described above, and may not have any confidentiality
>> requirements.
>> >  However, the same is not true of a single transaction or a
>> sequence
>> >  of transactions; that transaction is not / should not be
>> public.  A
>> >  typical example from outside the DNS world is: the web site of
>> >  Alcoholics Anonymous is public; the fact that you visit it
>> should not
>> >  be.
>>
>> Well, technically what you want to conceal is the origin of the
>> transaction or its linkage to other transactions. The existence of the
>> query for that A record isn't secret.
>>
>>
>> Suggest:
>>
>> “that transaction (and specifically the origin of that transaction)
>> is not / should not be public."
>>
>
> The parenthetical swallows the main sentence. The accurate thing to
> say is:
>
> In general, the existence of a single query is not sensitive -- though
> there may be exceptions
> for some very low use domains. However, the origin of a given query
> may leak information
> about specific users and the ability to link queries reveals
> information about individual use
> patterns.
>
>
> To fit with existing text suggest:
>
>  However, the same is not true of a single transaction or a sequence
>  of transactions; those transaction are not / should not be public. A
> single
>  transactions reveals both the originator of the query and the query
>  contents which potentially leaks sensitive information about a
> specific user. A
>  typical example from outside the DNS world is: the web site of
>  Alcoholics Anonymous is public; the fact that you visit it should not
>  be.
>

 I find this text a bit clumsy, but OK.


 Furthermore, the ability to link queries reveals information about
> individual use patterns.
>

 The key thing is "link queries as being from the same user”

>>>
>> OK - will include that.
>>
>>
>>

> 
>
>
>
>>
>>
>>
>>
>> S 3.4.2.
>> >  services available.  Given this, the choice of a user to
>> configure a
>> >  single resolver (or a fixed set of resolvers) and an encrypted
>> >  transport to use in all network environments can actually
>> serve to
>> >  identify the user as one that desires privacy and can provide
>> an
>> >  added mechanism to track them as they move across network
>> >  environments.
>>
>> I don't understand this paragraph. It's not the choice of specific
>> resolvers that leaks data, but the choice to turn on encryption, In
>> fact, from an identification purpose, the more resolvers that support
>> encrypted transport, the better signal this is.
>>
>>
>> This was driven by an observation that many early adopters set up
>> their own DoT server and used that from all their devices, which could 
>> act
>> as a way to identify that user.
>>
>
> 1. This seems like an edge case.
> 2. We already have plenty of people running their own unencrypted
> resolvers for other reasons.
>
>
> I can live with removing this text, but it does seem there is
> something to say about the fact configuring a single resolver for a device
> could differentiate a user….
>

 Sure, but this has nothing to do with DoH or DoT.


>>> I think the text might be clearer if the bit "as one that desires
>>> privacy and" were removed.
>>> The issue isn't whether a specific user desires privacy, it is whether a
>>> specific user can be identified and tracked.
>>>
>>> This RFC update, is about privacy.
>>> This particular section is on encrypted transport.
>>> This paragraph is highlighting that configuring a static list of
>>> resolvers, even if those use encrypted transport, may expose the user to
>>> privacy risks due to that constant set of resolvers, as the user moves
>>> between networks.
>>> And this risk is inversely proportional to the number of users of the
>>> resolver.
>>> Maybe this last bit needs to be 

Re: [dns-privacy] Datatracker State Update Notice:

[Sara Dickinson]

> On 6 Mar 2020, at 13:32, Eric Rescorla  wrote:
> 
> 
> 
> On Mon, Mar 2, 2020 at 7:16 AM Sara Dickinson  > wrote:
> 
> 
>> On 29 Feb 2020, at 02:03, Eric Rescorla > > wrote:
>> 
>> 
>> 
>> On Fri, Feb 28, 2020 at 4:50 PM Brian Dickson > > wrote:
>> 
>> 
>> On Fri, Feb 28, 2020 at 3:15 PM Eric Rescorla > > wrote:
>> 
>> 
>> On Wed, Feb 26, 2020 at 6:19 AM Sara Dickinson > > wrote:
>> 
>> 
>>> On 23 Jan 2020, at 13:53, Eric Rescorla >> > wrote:
>>> 
>>> On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson >> > wrote:
>>> 
 
 
 On 20 Jan 2020, at 22:37, Eric Rescorla >>> > wrote:
 
 Review comments attached:
 
 
 COMMENTS
 S 3.1.
 >  described above, and may not have any confidentiality requirements.
 >  However, the same is not true of a single transaction or a sequence
 >  of transactions; that transaction is not / should not be public.  A
 >  typical example from outside the DNS world is: the web site of
 >  Alcoholics Anonymous is public; the fact that you visit it should 
 > not
 >  be.
 
 Well, technically what you want to conceal is the origin of the
 transaction or its linkage to other transactions. The existence of the
 query for that A record isn't secret.
>>> 
>>> Suggest:
>>> 
>>> “that transaction (and specifically the origin of that transaction) is not 
>>> / should not be public."
>>> 
>>> The parenthetical swallows the main sentence. The accurate thing to say is:
>>> 
>>> In general, the existence of a single query is not sensitive -- though 
>>> there may be exceptions
>>> for some very low use domains. However, the origin of a given query may 
>>> leak information
>>> about specific users and the ability to link queries reveals information 
>>> about individual use
>>> patterns.
>> 
>> To fit with existing text suggest:
>> 
>>  However, the same is not true of a single transaction or a sequence
>>  of transactions; those transaction are not / should not be public. A single
>>  transactions reveals both the originator of the query and the query 
>>  contents which potentially leaks sensitive information about a specific 
>> user. A
>>  typical example from outside the DNS world is: the web site of
>>  Alcoholics Anonymous is public; the fact that you visit it should not
>>  be.  
>> 
>> I find this text a bit clumsy, but OK.
>> 
>> 
>> Furthermore, the ability to link queries reveals information about 
>> individual use patterns. 
>> 
>> The key thing is "link queries as being from the same user”
> 
> OK - will include that. 
> 
> 
>> 
>> 
>> 
>> 
>>> 
>>> 
 
 
 
 
 S 3.4.2.
 >  services available.  Given this, the choice of a user to configure a
 >  single resolver (or a fixed set of resolvers) and an encrypted
 >  transport to use in all network environments can actually serve to
 >  identify the user as one that desires privacy and can provide an
 >  added mechanism to track them as they move across network
 >  environments.
 
 I don't understand this paragraph. It's not the choice of specific
 resolvers that leaks data, but the choice to turn on encryption, In
 fact, from an identification purpose, the more resolvers that support
 encrypted transport, the better signal this is.
>>> 
>>> This was driven by an observation that many early adopters set up their own 
>>> DoT server and used that from all their devices, which could act as a way 
>>> to identify that user. 
>>> 
>>> 1. This seems like an edge case.
>>> 2. We already have plenty of people running their own unencrypted resolvers 
>>> for other reasons.
>> 
>> I can live with removing this text, but it does seem there is something to 
>> say about the fact configuring a single resolver for a device could 
>> differentiate a user….
>> 
>> Sure, but this has nothing to do with DoH or DoT.
>> 
>> 
>> I think the text might be clearer if the bit "as one that desires privacy 
>> and" were removed.
>> The issue isn't whether a specific user desires privacy, it is whether a 
>> specific user can be identified and tracked.
>> 
>> This RFC update, is about privacy. 
>> This particular section is on encrypted transport. 
>> This paragraph is highlighting that configuring a static list of resolvers, 
>> even if those use encrypted transport, may expose the user to privacy risks 
>> due to that constant set of resolvers, as the user moves between networks.
>> And this risk is inversely proportional to the number of users of the 
>> resolver.
>> Maybe this last bit needs to be added to emphasis why this is a risk?
>> 
>> It's about the fact that DoH/DoT don't protect against this or mitigate it, 
>> even if the payload is encrypted. I.e. it doesn't not have 

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IESG state changed:

New State: Waiting for AD Go-Ahead::Revised I-D Needed

(The previous state was In Last Call)


Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Rescorla]

On Mon, Mar 2, 2020 at 7:16 AM Sara Dickinson  wrote:

>
>
> On 29 Feb 2020, at 02:03, Eric Rescorla  wrote:
>
>
>
> On Fri, Feb 28, 2020 at 4:50 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Fri, Feb 28, 2020 at 3:15 PM Eric Rescorla  wrote:
>>
>>>
>>>
>>> On Wed, Feb 26, 2020 at 6:19 AM Sara Dickinson  wrote:
>>>


 On 23 Jan 2020, at 13:53, Eric Rescorla  wrote:

 On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson 
 wrote:



 On 20 Jan 2020, at 22:37, Eric Rescorla  wrote:

 Review comments attached:


 COMMENTS
> S 3.1.
> >  described above, and may not have any confidentiality
> requirements.
> >  However, the same is not true of a single transaction or a
> sequence
> >  of transactions; that transaction is not / should not be
> public.  A
> >  typical example from outside the DNS world is: the web site of
> >  Alcoholics Anonymous is public; the fact that you visit it
> should not
> >  be.
>
> Well, technically what you want to conceal is the origin of the
> transaction or its linkage to other transactions. The existence of the
> query for that A record isn't secret.
>
>
> Suggest:
>
> “that transaction (and specifically the origin of that transaction) is
> not / should not be public."
>

 The parenthetical swallows the main sentence. The accurate thing to say
 is:

 In general, the existence of a single query is not sensitive -- though
 there may be exceptions
 for some very low use domains. However, the origin of a given query may
 leak information
 about specific users and the ability to link queries reveals
 information about individual use
 patterns.


 To fit with existing text suggest:

  However, the same is not true of a single transaction or a sequence
  of transactions; those transaction are not / should not be public. A
 single
  transactions reveals both the originator of the query and the query
  contents which potentially leaks sensitive information about a
 specific user. A
  typical example from outside the DNS world is: the web site of
  Alcoholics Anonymous is public; the fact that you visit it should not
  be.

>>>
>>> I find this text a bit clumsy, but OK.
>>>
>>>
>>> Furthermore, the ability to link queries reveals information about
 individual use patterns.

>>>
>>> The key thing is "link queries as being from the same user”
>>>
>>
> OK - will include that.
>
>
>
>>>
 



>
>
>
>
> S 3.4.2.
> >  services available.  Given this, the choice of a user to
> configure a
> >  single resolver (or a fixed set of resolvers) and an encrypted
> >  transport to use in all network environments can actually serve
> to
> >  identify the user as one that desires privacy and can provide an
> >  added mechanism to track them as they move across network
> >  environments.
>
> I don't understand this paragraph. It's not the choice of specific
> resolvers that leaks data, but the choice to turn on encryption, In
> fact, from an identification purpose, the more resolvers that support
> encrypted transport, the better signal this is.
>
>
> This was driven by an observation that many early adopters set up
> their own DoT server and used that from all their devices, which could act
> as a way to identify that user.
>

 1. This seems like an edge case.
 2. We already have plenty of people running their own unencrypted
 resolvers for other reasons.


 I can live with removing this text, but it does seem there is something
 to say about the fact configuring a single resolver for a device could
 differentiate a user….

>>>
>>> Sure, but this has nothing to do with DoH or DoT.
>>>
>>>
>> I think the text might be clearer if the bit "as one that desires privacy
>> and" were removed.
>> The issue isn't whether a specific user desires privacy, it is whether a
>> specific user can be identified and tracked.
>>
>> This RFC update, is about privacy.
>> This particular section is on encrypted transport.
>> This paragraph is highlighting that configuring a static list of
>> resolvers, even if those use encrypted transport, may expose the user to
>> privacy risks due to that constant set of resolvers, as the user moves
>> between networks.
>> And this risk is inversely proportional to the number of users of the
>> resolver.
>> Maybe this last bit needs to be added to emphasis why this is a risk?
>>
>> It's about the fact that DoH/DoT don't protect against this or mitigate
>> it, even if the payload is encrypted. I.e. it doesn't not have anything to
>> do with DoH/DoT; it's bigger than DoH/DoT, and DoH/DoT don't fix the
>> problem.
>>
>
> Yes, I 

Re: [dns-privacy] Datatracker State Update Notice:

[Sara Dickinson]

> On 3 Mar 2020, at 11:34, Vittorio Bertola  
> wrote:
> 
> 
>> Il 02/03/2020 16:16 Sara Dickinson  ha scritto:
>> 
>> Suggest: 
>> 
>> "For users to have the ability to inspect and control the 
>> application-specific DNS settings in a similar fashion to the OS DNS 
>> settings, each application also needs to: 
>> 
>>o  expose the default settings to the user 
>> 
>>o  provide configuration options to manually override the default 
>> settings so that resolution is performed via
>>   * user specified resolvers
>>   * the resolvers configured into the system settings
>>   * the system resolver via conventional API calls
>> 
>> If all such applications are updated to use the system resolver, as 
>> described in the last bullet point, the device reverts to a single point of 
>> control for all DNS queries."
> I don't want to nitpick, but I'd point out that from the policy/privacy 
> viewpoint what is important is which resolver is used, not (as long as it 
> does not add any specific new privacy risk) the interface used to contact it 
> - so the second and third "*" bullets are functionally equivalent and it 
> would be fine if an application provided only either one of the two. 

You are broadly correct,  but there are some small differences in that for the 
second bullet point not all applications may offer the preferred transport 
(e.g. most browsers don’t support DoT but my preferred resolver might only 
support DoT) or config options e.g. to omit the User-agent HTTP header. It will 
also mean X different applications making X different connections to the 
resolver (which could reveal the set of applications the user has installed). 
Whereas if everything goes through the system resolver the device appears to 
the resolver as a single source of queries using a set of connections managed 
only from the system resolver. 

> 
> In theory, one could say that the two interfaces are not completely 
> privacy-equivalent, since the use of the system API introduces one more party 
> that gets access to data, i.e. the operating system - so one could argue that 
> applications should bypass the OS to prevent it from spying over the user's 
> DNS traffic, exactly like they do with the network. If this is what we want 
> to argue, then we should remove the last "*" bullet. However, exactly as the 
> network, the OS might want to exert some general policy over the user's DNS 
> traffic, such as monitoring infections or filtering specific destinations, so 
> I don't know if such a recommendation would be beneficial in the end. 


This is an interesting point! Note that a user may want to use the system 
resolver as a point to monitor their own traffic. For example, having multiple 
sources of DNS queries doesn’t necessarily provide the same ability to 
troubleshoot issues as a single component does, or (more importantly) to 
inspect the encrypted traffic leaving the machine. Firefox nicely allows users 
to export session keys so the traffic can be decrypted locally (and also 
provides an interface to look at the DNS results), but if an application 
doesn’t offer this then the user may have no ability to easily see their own 
DNS traffic. I’ve thought in the past of proposing this as an additional option 
for the applications (and in future on any OS that implements an encrypted 
transport) but didn’t follow up.

Sara. 


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Vittorio Bertola]

> Il 02/03/2020 16:16 Sara Dickinson  ha scritto:
> 
> Suggest: 
> 
> "For users to have the ability to inspect and control the 
> application-specific DNS settings in a similar fashion to the OS DNS 
> settings, each application also needs to:
> 
>o  expose the default settings to the user
> 
>o  provide configuration options to manually override the default 
> settings so that resolution is performed via
>   * user specified resolvers
>   * the resolvers configured into the system settings
>   * the system resolver via conventional API calls
> 
> If all such applications are updated to use the system resolver, as 
> described in the last bullet point, the device reverts to a single point of 
> control for all DNS queries."
> 
I don't want to nitpick, but I'd point out that from the policy/privacy 
viewpoint what is important is which resolver is used, not (as long as it does 
not add any specific new privacy risk) the interface used to contact it - so 
the second and third "*" bullets are functionally equivalent and it would be 
fine if an application provided only either one of the two.

In theory, one could say that the two interfaces are not completely 
privacy-equivalent, since the use of the system API introduces one more party 
that gets access to data, i.e. the operating system - so one could argue that 
applications should bypass the OS to prevent it from spying over the user's DNS 
traffic, exactly like they do with the network. If this is what we want to 
argue, then we should remove the last "*" bullet. However, exactly as the 
network, the OS might want to exert some general policy over the user's DNS 
traffic, such as monitoring infections or filtering specific destinations, so I 
don't know if such a recommendation would be beneficial in the end.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Sara Dickinson]

> On 29 Feb 2020, at 02:03, Eric Rescorla  wrote:
> 
> 
> 
> On Fri, Feb 28, 2020 at 4:50 PM Brian Dickson  > wrote:
> 
> 
> On Fri, Feb 28, 2020 at 3:15 PM Eric Rescorla  > wrote:
> 
> 
> On Wed, Feb 26, 2020 at 6:19 AM Sara Dickinson  > wrote:
> 
> 
>> On 23 Jan 2020, at 13:53, Eric Rescorla > > wrote:
>> 
>> On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson > > wrote:
>> 
>>> 
>>> 
>>> On 20 Jan 2020, at 22:37, Eric Rescorla >> > wrote:
>>> 
>>> Review comments attached:
>>> 
>>> 
>>> COMMENTS
>>> S 3.1.
>>> >  described above, and may not have any confidentiality requirements.
>>> >  However, the same is not true of a single transaction or a sequence
>>> >  of transactions; that transaction is not / should not be public.  A
>>> >  typical example from outside the DNS world is: the web site of
>>> >  Alcoholics Anonymous is public; the fact that you visit it should not
>>> >  be.
>>> 
>>> Well, technically what you want to conceal is the origin of the
>>> transaction or its linkage to other transactions. The existence of the
>>> query for that A record isn't secret.
>> 
>> Suggest:
>> 
>> “that transaction (and specifically the origin of that transaction) is not / 
>> should not be public."
>> 
>> The parenthetical swallows the main sentence. The accurate thing to say is:
>> 
>> In general, the existence of a single query is not sensitive -- though there 
>> may be exceptions
>> for some very low use domains. However, the origin of a given query may leak 
>> information
>> about specific users and the ability to link queries reveals information 
>> about individual use
>> patterns.
> 
> To fit with existing text suggest:
> 
>  However, the same is not true of a single transaction or a sequence
>  of transactions; those transaction are not / should not be public. A single
>  transactions reveals both the originator of the query and the query 
>  contents which potentially leaks sensitive information about a specific 
> user. A
>  typical example from outside the DNS world is: the web site of
>  Alcoholics Anonymous is public; the fact that you visit it should not
>  be.  
> 
> I find this text a bit clumsy, but OK.
> 
> 
> Furthermore, the ability to link queries reveals information about individual 
> use patterns. 
> 
> The key thing is "link queries as being from the same user”

OK - will include that. 


> 
> 
> 
> 
>> 
>> 
>>> 
>>> 
>>> 
>>> 
>>> S 3.4.2.
>>> >  services available.  Given this, the choice of a user to configure a
>>> >  single resolver (or a fixed set of resolvers) and an encrypted
>>> >  transport to use in all network environments can actually serve to
>>> >  identify the user as one that desires privacy and can provide an
>>> >  added mechanism to track them as they move across network
>>> >  environments.
>>> 
>>> I don't understand this paragraph. It's not the choice of specific
>>> resolvers that leaks data, but the choice to turn on encryption, In
>>> fact, from an identification purpose, the more resolvers that support
>>> encrypted transport, the better signal this is.
>> 
>> This was driven by an observation that many early adopters set up their own 
>> DoT server and used that from all their devices, which could act as a way to 
>> identify that user. 
>> 
>> 1. This seems like an edge case.
>> 2. We already have plenty of people running their own unencrypted resolvers 
>> for other reasons.
> 
> I can live with removing this text, but it does seem there is something to 
> say about the fact configuring a single resolver for a device could 
> differentiate a user….
> 
> Sure, but this has nothing to do with DoH or DoT.
> 
> 
> I think the text might be clearer if the bit "as one that desires privacy 
> and" were removed.
> The issue isn't whether a specific user desires privacy, it is whether a 
> specific user can be identified and tracked.
> 
> This RFC update, is about privacy. 
> This particular section is on encrypted transport. 
> This paragraph is highlighting that configuring a static list of resolvers, 
> even if those use encrypted transport, may expose the user to privacy risks 
> due to that constant set of resolvers, as the user moves between networks.
> And this risk is inversely proportional to the number of users of the 
> resolver.
> Maybe this last bit needs to be added to emphasis why this is a risk?
> 
> It's about the fact that DoH/DoT don't protect against this or mitigate it, 
> even if the payload is encrypted. I.e. it doesn't not have anything to do 
> with DoH/DoT; it's bigger than DoH/DoT, and DoH/DoT don't fix the problem.
> 
> Yes, I agree with that, but this risk is generic to DNS even if you use your 
> own resolver (e.g., pihole) which we know people do. Therefore it does not 
> belong in this section as a risk of DoH/DoT..

I think the more 

Re: [dns-privacy] Datatracker State Update Notice:

[Stephen Farrell]

Hiya,

On 29/02/2020 00:49, Brian Dickson wrote:
> And this risk is inversely proportional to the number of users of the
> resolver.

I don't think the above is a good description of the
situation with DNS recursives.

My own intuition is that the risk vs. percentage of users
per recursive for a set of DNS recursive resolvers would
be more like a "U" shaped curve with risk-maxima near 1
user/recursive and also near 100% of users on one
recursive.

However, I'm not sure the idea of such a distribution
is so useful, as DNS recursives can be interdependent,
and traffic patterns will also matter.

Cheers,
S.





0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Rescorla]

On Fri, Feb 28, 2020 at 4:50 PM Brian Dickson 
wrote:

>
>
> On Fri, Feb 28, 2020 at 3:15 PM Eric Rescorla  wrote:
>
>>
>>
>> On Wed, Feb 26, 2020 at 6:19 AM Sara Dickinson  wrote:
>>
>>>
>>>
>>> On 23 Jan 2020, at 13:53, Eric Rescorla  wrote:
>>>
>>> On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson  wrote:
>>>
>>>
>>>
>>> On 20 Jan 2020, at 22:37, Eric Rescorla  wrote:
>>>
>>> Review comments attached:
>>>
>>>
>>> COMMENTS
 S 3.1.
 >  described above, and may not have any confidentiality
 requirements.
 >  However, the same is not true of a single transaction or a
 sequence
 >  of transactions; that transaction is not / should not be public..
  A
 >  typical example from outside the DNS world is: the web site of
 >  Alcoholics Anonymous is public; the fact that you visit it
 should not
 >  be.

 Well, technically what you want to conceal is the origin of the
 transaction or its linkage to other transactions. The existence of the
 query for that A record isn't secret.


 Suggest:

 “that transaction (and specifically the origin of that transaction) is
 not / should not be public."

>>>
>>> The parenthetical swallows the main sentence. The accurate thing to say
>>> is:
>>>
>>> In general, the existence of a single query is not sensitive -- though
>>> there may be exceptions
>>> for some very low use domains. However, the origin of a given query may
>>> leak information
>>> about specific users and the ability to link queries reveals information
>>> about individual use
>>> patterns.
>>>
>>>
>>> To fit with existing text suggest:
>>>
>>>  However, the same is not true of a single transaction or a sequence
>>>  of transactions; those transaction are not / should not be public. A
>>> single
>>>  transactions reveals both the originator of the query and the query
>>>  contents which potentially leaks sensitive information about a specific
>>> user. A
>>>  typical example from outside the DNS world is: the web site of
>>>  Alcoholics Anonymous is public; the fact that you visit it should not
>>>  be.
>>>
>>
>> I find this text a bit clumsy, but OK.
>>
>>
>> Furthermore, the ability to link queries reveals information about
>>> individual use patterns.
>>>
>>
>> The key thing is "link queries as being from the same user"
>>
>>
>>> 
>>>
>>>
>>>




 S 3.4.2.
 >  services available.  Given this, the choice of a user to
 configure a
 >  single resolver (or a fixed set of resolvers) and an encrypted
 >  transport to use in all network environments can actually serve
 to
 >  identify the user as one that desires privacy and can provide an
 >  added mechanism to track them as they move across network
 >  environments.

 I don't understand this paragraph. It's not the choice of specific
 resolvers that leaks data, but the choice to turn on encryption, In
 fact, from an identification purpose, the more resolvers that support
 encrypted transport, the better signal this is.


 This was driven by an observation that many early adopters set up their
 own DoT server and used that from all their devices, which could act as a
 way to identify that user.

>>>
>>> 1. This seems like an edge case.
>>> 2. We already have plenty of people running their own unencrypted
>>> resolvers for other reasons.
>>>
>>>
>>> I can live with removing this text, but it does seem there is something
>>> to say about the fact configuring a single resolver for a device could
>>> differentiate a user….
>>>
>>
>> Sure, but this has nothing to do with DoH or DoT.
>>
>>
> I think the text might be clearer if the bit "as one that desires privacy
> and" were removed.
> The issue isn't whether a specific user desires privacy, it is whether a
> specific user can be identified and tracked.
>
> This RFC update, is about privacy.
> This particular section is on encrypted transport.
> This paragraph is highlighting that configuring a static list of
> resolvers, even if those use encrypted transport, may expose the user to
> privacy risks due to that constant set of resolvers, as the user moves
> between networks.
> And this risk is inversely proportional to the number of users of the
> resolver.
> Maybe this last bit needs to be added to emphasis why this is a risk?
>
> It's about the fact that DoH/DoT don't protect against this or mitigate
> it, even if the payload is encrypted. I.e. it doesn't not have anything to
> do with DoH/DoT; it's bigger than DoH/DoT, and DoH/DoT don't fix the
> problem.
>

Yes, I agree with that, but this risk is generic to DNS even if you use
your own resolver (e.g., pihole) which we know people do. Therefore it does
not belong in this section as a risk of DoH/DoT..


>
>>
>>
>>>
>>>

 S 3.5.1..1.2.
 >
 >  o  communicate clearly the change in default to users
 >
 >  o  provide 

Re: [dns-privacy] Datatracker State Update Notice:

[Brian Dickson]

On Fri, Feb 28, 2020 at 3:15 PM Eric Rescorla  wrote:

>
>
> On Wed, Feb 26, 2020 at 6:19 AM Sara Dickinson  wrote:
>
>>
>>
>> On 23 Jan 2020, at 13:53, Eric Rescorla  wrote:
>>
>> On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson  wrote:
>>
>>
>>
>> On 20 Jan 2020, at 22:37, Eric Rescorla  wrote:
>>
>> Review comments attached:
>>
>>
>> COMMENTS
>>> S 3.1.
>>> >  described above, and may not have any confidentiality
>>> requirements.
>>> >  However, the same is not true of a single transaction or a
>>> sequence
>>> >  of transactions; that transaction is not / should not be public.
>>>  A
>>> >  typical example from outside the DNS world is: the web site of
>>> >  Alcoholics Anonymous is public; the fact that you visit it should
>>> not
>>> >  be.
>>>
>>> Well, technically what you want to conceal is the origin of the
>>> transaction or its linkage to other transactions. The existence of the
>>> query for that A record isn't secret.
>>>
>>>
>>> Suggest:
>>>
>>> “that transaction (and specifically the origin of that transaction) is
>>> not / should not be public."
>>>
>>
>> The parenthetical swallows the main sentence. The accurate thing to say
>> is:
>>
>> In general, the existence of a single query is not sensitive -- though
>> there may be exceptions
>> for some very low use domains. However, the origin of a given query may
>> leak information
>> about specific users and the ability to link queries reveals information
>> about individual use
>> patterns.
>>
>>
>> To fit with existing text suggest:
>>
>>  However, the same is not true of a single transaction or a sequence
>>  of transactions; those transaction are not / should not be public. A
>> single
>>  transactions reveals both the originator of the query and the query
>>  contents which potentially leaks sensitive information about a specific
>> user. A
>>  typical example from outside the DNS world is: the web site of
>>  Alcoholics Anonymous is public; the fact that you visit it should not
>>  be.
>>
>
> I find this text a bit clumsy, but OK.
>
>
> Furthermore, the ability to link queries reveals information about
>> individual use patterns.
>>
>
> The key thing is "link queries as being from the same user"
>
>
>> 
>>
>>
>>
>>>
>>>
>>>
>>>
>>> S 3.4.2.
>>> >  services available.  Given this, the choice of a user to
>>> configure a
>>> >  single resolver (or a fixed set of resolvers) and an encrypted
>>> >  transport to use in all network environments can actually serve to
>>> >  identify the user as one that desires privacy and can provide an
>>> >  added mechanism to track them as they move across network
>>> >  environments.
>>>
>>> I don't understand this paragraph. It's not the choice of specific
>>> resolvers that leaks data, but the choice to turn on encryption, In
>>> fact, from an identification purpose, the more resolvers that support
>>> encrypted transport, the better signal this is.
>>>
>>>
>>> This was driven by an observation that many early adopters set up their
>>> own DoT server and used that from all their devices, which could act as a
>>> way to identify that user.
>>>
>>
>> 1. This seems like an edge case.
>> 2. We already have plenty of people running their own unencrypted
>> resolvers for other reasons.
>>
>>
>> I can live with removing this text, but it does seem there is something
>> to say about the fact configuring a single resolver for a device could
>> differentiate a user….
>>
>
> Sure, but this has nothing to do with DoH or DoT.
>
>
I think the text might be clearer if the bit "as one that desires privacy
and" were removed.
The issue isn't whether a specific user desires privacy, it is whether a
specific user can be identified and tracked.

This RFC update, is about privacy.
This particular section is on encrypted transport.
This paragraph is highlighting that configuring a static list of resolvers,
even if those use encrypted transport, may expose the user to privacy risks
due to that constant set of resolvers, as the user moves between networks.
And this risk is inversely proportional to the number of users of the
resolver.
Maybe this last bit needs to be added to emphasis why this is a risk?

It's about the fact that DoH/DoT don't protect against this or mitigate it,
even if the payload is encrypted. I.e. it doesn't not have anything to do
with DoH/DoT; it's bigger than DoH/DoT, and DoH/DoT don't fix the problem.



>
>
>>
>>
>>>
>>> S 3.5.1..1.2.
>>> >
>>> >  o  communicate clearly the change in default to users
>>> >
>>> >  o  provide configuration options to change the default
>>> >
>>> >  o  provide configuration options to always use the system resolver
>>>
>>> I get that you think this is neutral, but all of this is equally true
>>> about dynamic discovery via DHCP, it's just that that's the status
>>> quo, so you don't notice it. In this context, this text is tendentious.
>>>
>>>
>>> The first paragraph of section 3.5.1.1 talks about the variability 

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Rescorla]

On Wed, Feb 26, 2020 at 6:19 AM Sara Dickinson  wrote:

>
>
> On 23 Jan 2020, at 13:53, Eric Rescorla  wrote:
>
> On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson  wrote:
>
>
>
> On 20 Jan 2020, at 22:37, Eric Rescorla  wrote:
>
> Review comments attached:
>
>
> COMMENTS
>> S 3.1.
>> >  described above, and may not have any confidentiality requirements.
>> >  However, the same is not true of a single transaction or a sequence
>> >  of transactions; that transaction is not / should not be public.  A
>> >  typical example from outside the DNS world is: the web site of
>> >  Alcoholics Anonymous is public; the fact that you visit it should
>> not
>> >  be.
>>
>> Well, technically what you want to conceal is the origin of the
>> transaction or its linkage to other transactions. The existence of the
>> query for that A record isn't secret.
>>
>>
>> Suggest:
>>
>> “that transaction (and specifically the origin of that transaction) is
>> not / should not be public."
>>
>
> The parenthetical swallows the main sentence. The accurate thing to say is:
>
> In general, the existence of a single query is not sensitive -- though
> there may be exceptions
> for some very low use domains. However, the origin of a given query may
> leak information
> about specific users and the ability to link queries reveals information
> about individual use
> patterns.
>
>
> To fit with existing text suggest:
>
>  However, the same is not true of a single transaction or a sequence
>  of transactions; those transaction are not / should not be public. A
> single
>  transactions reveals both the originator of the query and the query
>  contents which potentially leaks sensitive information about a specific
> user. A
>  typical example from outside the DNS world is: the web site of
>  Alcoholics Anonymous is public; the fact that you visit it should not
>  be.
>

I find this text a bit clumsy, but OK.


Furthermore, the ability to link queries reveals information about
> individual use patterns.
>

The key thing is "link queries as being from the same user"


> 
>
>
>
>>
>>
>>
>>
>> S 3.4.2.
>> >  services available.  Given this, the choice of a user to configure
>> a
>> >  single resolver (or a fixed set of resolvers) and an encrypted
>> >  transport to use in all network environments can actually serve to
>> >  identify the user as one that desires privacy and can provide an
>> >  added mechanism to track them as they move across network
>> >  environments.
>>
>> I don't understand this paragraph. It's not the choice of specific
>> resolvers that leaks data, but the choice to turn on encryption, In
>> fact, from an identification purpose, the more resolvers that support
>> encrypted transport, the better signal this is.
>>
>>
>> This was driven by an observation that many early adopters set up their
>> own DoT server and used that from all their devices, which could act as a
>> way to identify that user.
>>
>
> 1. This seems like an edge case.
> 2. We already have plenty of people running their own unencrypted
> resolvers for other reasons.
>
>
> I can live with removing this text, but it does seem there is something to
> say about the fact configuring a single resolver for a device could
> differentiate a user….
>

Sure, but this has nothing to do with DoH or DoT.



>
>
>>
>> S 3.5.1..1.2.
>> >
>> >  o  communicate clearly the change in default to users
>> >
>> >  o  provide configuration options to change the default
>> >
>> >  o  provide configuration options to always use the system resolver
>>
>> I get that you think this is neutral, but all of this is equally true
>> about dynamic discovery via DHCP, it's just that that's the status
>> quo, so you don't notice it. In this context, this text is tendentious.
>>
>>
>> The first paragraph of section 3.5.1.1 talks about the variability of DNS
>> resolution privacy with network (assuming DHCP). I can add some text there
>> to better explain the status quo if you think it is needed. Suggest:
>>
>> “Typically joining a new network requires some form of user action (e.g
>> physically plugging in a cable or selecting a network in a OS dialogue) and
>> so a user is also implicitly choosing to use the DHCP-provided resolver via
>> this action too."
>>
>
> The user has no idea that such a DHCP resolver even exists. And you could
> say the same thing about the user's choice to install an application with
> its own resolver selection logic.
>
>
>
>> I can’t think of a mobile or desktop OS that doesn’t allow users to
>> override the DHCP provided DNS settings…. but I could text about that in
>> section 5.1.1. if you really think it is needed?
>>
>
> This isn't about that. AFAICT most major applications also allow you to
> use the system resolver choices. Rather, the issue here is the repeated
> arguments in this discussion (which you implicitly accept above) that the
> current status quo somehow represents user choice whereas an 

Re: [dns-privacy] Datatracker State Update Notice:

[Sara Dickinson]

> On 23 Jan 2020, at 13:53, Eric Rescorla  wrote:
> 
> On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson  wrote:
> 
>> 
>> 
>> On 20 Jan 2020, at 22:37, Eric Rescorla  wrote:
>> 
>> Review comments attached:
>> 
>> 
>> COMMENTS
>> S 3.1.
>> >  described above, and may not have any confidentiality requirements.
>> >  However, the same is not true of a single transaction or a sequence
>> >  of transactions; that transaction is not / should not be public.  A
>> >  typical example from outside the DNS world is: the web site of
>> >  Alcoholics Anonymous is public; the fact that you visit it should not
>> >  be.
>> 
>> Well, technically what you want to conceal is the origin of the
>> transaction or its linkage to other transactions. The existence of the
>> query for that A record isn't secret.
> 
> Suggest:
> 
> “that transaction (and specifically the origin of that transaction) is not / 
> should not be public."
> 
> The parenthetical swallows the main sentence. The accurate thing to say is:
> 
> In general, the existence of a single query is not sensitive -- though there 
> may be exceptions
> for some very low use domains. However, the origin of a given query may leak 
> information
> about specific users and the ability to link queries reveals information 
> about individual use
> patterns.

To fit with existing text suggest:

 However, the same is not true of a single transaction or a sequence
 of transactions; those transaction are not / should not be public. A single 
 transactions reveals both the originator of the query and the query 
 contents which potentially leaks sensitive information about a specific user. A
 typical example from outside the DNS world is: the web site of
 Alcoholics Anonymous is public; the fact that you visit it should not
 be.  Furthermore, the ability to link queries reveals information about 
individual use patterns. 



> 
> 
>> 
>> 
>> 
>> 
>> S 3.4.2.
>> >  services available.  Given this, the choice of a user to configure a
>> >  single resolver (or a fixed set of resolvers) and an encrypted
>> >  transport to use in all network environments can actually serve to
>> >  identify the user as one that desires privacy and can provide an
>> >  added mechanism to track them as they move across network
>> >  environments.
>> 
>> I don't understand this paragraph. It's not the choice of specific
>> resolvers that leaks data, but the choice to turn on encryption, In
>> fact, from an identification purpose, the more resolvers that support
>> encrypted transport, the better signal this is.
> 
> This was driven by an observation that many early adopters set up their own 
> DoT server and used that from all their devices, which could act as a way to 
> identify that user. 
> 
> 1. This seems like an edge case.
> 2. We already have plenty of people running their own unencrypted resolvers 
> for other reasons.

I can live with removing this text, but it does seem there is something to say 
about the fact configuring a single resolver for a device could differentiate a 
user….

> 
>> 
>> 
>> S 3.5.1..1.2.
>> >   
>> >  o  communicate clearly the change in default to users
>> >   
>> >  o  provide configuration options to change the default
>> >   
>> >  o  provide configuration options to always use the system resolver
>> 
>> I get that you think this is neutral, but all of this is equally true
>> about dynamic discovery via DHCP, it's just that that's the status
>> quo, so you don't notice it. In this context, this text is tendentious.
> 
> The first paragraph of section 3.5.1.1 talks about the variability of DNS 
> resolution privacy with network (assuming DHCP). I can add some text there to 
> better explain the status quo if you think it is needed. Suggest:
> 
> “Typically joining a new network requires some form of user action (e.g 
> physically plugging in a cable or selecting a network in a OS dialogue) and 
> so a user is also implicitly choosing to use the DHCP-provided resolver via 
> this action too."
> 
> The user has no idea that such a DHCP resolver even exists. And you could say 
> the same thing about the user's choice to install an application with its own 
> resolver selection logic.
> 
> 
> I can’t think of a mobile or desktop OS that doesn’t allow users to override 
> the DHCP provided DNS settings…. but I could text about that in section 
> 5.1.1. if you really think it is needed?
> 
> This isn't about that. AFAICT most major applications also allow you to use 
> the system resolver choices. Rather, the issue here is the repeated arguments 
> in this discussion (which you implicitly accept above) that the current 
> status quo somehow represents user choice whereas an application choosing its 
> own resolver does not. And both this text and your proposed text implicitly 
> takes a position on that.

I think that is reading quite a bit into the text however, to reduce any 
implicit misinterpretation I 

Re: [dns-privacy] Datatracker State Update Notice:

[Sara Dickinson]

All, 

Many apologies for the very slow follow up on this - I was out of the office 
for far longer than expected. I’ll follow up and have an update I-D available 
in the next couple of days.

Sara. 

> On 4 Feb 2020, at 07:44, IETF Secretariat  
> wrote:
> 
> IESG state changed:
> 
> New State: Waiting for AD Go-Ahead::Revised I-D Needed
> 
> (The previous state was Waiting for AD Go-Ahead::AD Followup)
> 
> To address the comments received during IETF Last Call.
> 
> Datatracker URL: 
> https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/
> 

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[S Moonesamy]

Hi Eric,

There was the following comment during the Last Call: "18 of these 
points relate to text that is unchanged since the original RFC7626, 
I'll mark these as [RFC7626].  To avoid repetition I'll outline that 
since this text has already received two forms of consensus ..."


The "two forms of consensus" is something which I don't see in any 
"process" document.  Could an Area Director please clarify how that 
"two forms of consensus" works?


Regards,
S. Moonesamy

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Rob Sayre]

Hi,

While I don't want to obstruct progress on this draft, I do intend to write
a draft that addresses my points and aims to obsolete rfc7626-bis.

This topic can be contentious, so I don't have an eventual RFC as a goal
(but that would be ok).

thanks,
Rob


On Mon, Feb 3, 2020 at 11:44 PM Eric Vyncke (evyncke) 
wrote:

> [- WG mailing list - secretariat]
>
> Dear authors [Sara no need for urgent reply],
>
> There were little reactions during the Last Call. Do you want to issue an
> revised ID or simply go ahead with the current revision ? With Rob Sayre's
> 45 points, a revised I-D is really required (and Sara has already replied
> to all points, so, just need to issue the text).
>
> Hence, I am changing the state to 'revised I-D needed', then the last mile
> run with IESG ballot __
>
> -éric
>
> On 03/02/2020, 20:17, "IETF Secretariat" 
> wrote:
>
> IESG state changed:
>
> New State: Waiting for AD Go-Ahead::AD Followup
>
> (The previous state was Waiting for AD Go-Ahead)
>
>
> Datatracker URL:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/
>
>
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IESG state changed:

New State: Waiting for AD Go-Ahead::Revised I-D Needed

(The previous state was Waiting for AD Go-Ahead::AD Followup)

To address the comments received during IETF Last Call.

Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Vyncke (evyncke)]

[- WG mailing list - secretariat]

Dear authors [Sara no need for urgent reply],

There were little reactions during the Last Call. Do you want to issue an 
revised ID or simply go ahead with the current revision ? With Rob Sayre's 45 
points, a revised I-D is really required (and Sara has already replied to all 
points, so, just need to issue the text).

Hence, I am changing the state to 'revised I-D needed', then the last mile run 
with IESG ballot __

-éric

On 03/02/2020, 20:17, "IETF Secretariat"  
wrote:

IESG state changed:

New State: Waiting for AD Go-Ahead::AD Followup

(The previous state was Waiting for AD Go-Ahead)


Datatracker URL: 
https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/



___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IESG state changed:

New State: Waiting for AD Go-Ahead::AD Followup

(The previous state was Waiting for AD Go-Ahead)


Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IANA review state changed to "IANA OK - No Actions Needed"
Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Sara Dickinson]

Hi All, 

Please note that I will be out of the office next week and not reading email. I 
will continue to respond to IETF Last call comments on my return. 

Best regards

Sara. 

> On 20 Jan 2020, at 21:45, Eric Vyncke (evyncke)  wrote:
> 
> Thanks to Sara and Stéphane for the -04 revised I-D. 
> 
> After reading the -04, I think that most of the IETF Last Call comments are 
> addressed (and consensus needs to be balanced -- even for informational 
> document) and that the document sticks to facts.
> 
> But, as section 3.5.1 ("in the recursive resolvers") raised a lot of 
> discussions during the first IETF Last Call, and as the authors reacted to 
> those comments by deep changes in the text, let's have a new IETF Last Call 
> before proceeding with IESG evaluation.
> 
> Again, thank you to the reviewers and the authors
> 
> Regards,
> 
> -éric
> 
> 
> On 20/01/2020, 22:34, "IETF Secretariat"  
> wrote:
> 
>IESG state changed:
> 
>New State: Last Call Requested
> 
>(The previous state was Waiting for AD Go-Ahead::AD Followup)
> 
>The previous last call raised several points. The authors have worked on 
> those points and this new informational IETF draft has substantive changes; 
> enough to go trigger a new IETF Last Call.
> 
>-éric
> 
>Datatracker URL: 
> https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/
> 
> 
> 
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Rescorla]

On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson  wrote:

>
>
> On 20 Jan 2020, at 22:37, Eric Rescorla  wrote:
>
> Review comments attached:
>
>
> COMMENTS
> S 3.1.
> >  described above, and may not have any confidentiality requirements..
> >  However, the same is not true of a single transaction or a sequence
> >  of transactions; that transaction is not / should not be public.  A
> >  typical example from outside the DNS world is: the web site of
> >  Alcoholics Anonymous is public; the fact that you visit it should
> not
> >  be.
>
> Well, technically what you want to conceal is the origin of the
> transaction or its linkage to other transactions. The existence of the
> query for that A record isn't secret.
>
>
> Suggest:
>
> “that transaction (and specifically the origin of that transaction) is not
> / should not be public."
>

The parenthetical swallows the main sentence. The accurate thing to say is:

In general, the existence of a single query is not sensitive -- though
there may be exceptions
for some very low use domains. However, the origin of a given query may
leak information
about specific users and the ability to link queries reveals information
about individual use
patterns.


>
>
>
>
> S 3.4.2.
> >  fingerprint [2] values can be used to fingerprint client OS's or
> that
> >  various techniques can be used to de-NAT DNS queries dns-de-nat [3].
> >
> >  Note that even when using encrypted transports the use of clear text
> >  transport options to decrease latency can provide correlation of a
> >  users' connections e.g.  using TCP Fast Open [RFC7413] with TLS 1.2.
>
> Why does this say TLS 1.2? Any use of TFO will have the same
> properties.
>
> Perhaps you are thinking of TLS session tickets here?
>
>
> Sorry - hangover from earlier text, will remove. The last previously
> agreed text was (in email of 31 Dec):
>
> “Note that even when using encrypted transports the use of clear text
> transport options to decrease latency can provide correlation of a users'
> connections e.g. using TCP Fast Open [RFC7413]."
>

Yes, I think that's fine.



>
>
>
>
> S 3.4.2.
> >  services available.  Given this, the choice of a user to configure a
> >  single resolver (or a fixed set of resolvers) and an encrypted
> >  transport to use in all network environments can actually serve to
> >  identify the user as one that desires privacy and can provide an
> >  added mechanism to track them as they move across network
> >  environments.
>
> I don't understand this paragraph. It's not the choice of specific
> resolvers that leaks data, but the choice to turn on encryption, In
> fact, from an identification purpose, the more resolvers that support
> encrypted transport, the better signal this is.
>
>
> This was driven by an observation that many early adopters set up their
> own DoT server and used that from all their devices, which could act as a
> way to identify that user.
>

1. This seems like an edge case.
2. We already have plenty of people running their own unencrypted resolvers
for other reasons.


>
> S 3.5.1.1.2.
> >
> >  o  communicate clearly the change in default to users
> >
> >  o  provide configuration options to change the default
> >
> >  o  provide configuration options to always use the system resolver
>
> I get that you think this is neutral, but all of this is equally true
> about dynamic discovery via DHCP, it's just that that's the status
> quo, so you don't notice it. In this context, this text is tendentious.
>
>
> The first paragraph of section 3.5.1.1 talks about the variability of DNS
> resolution privacy with network (assuming DHCP). I can add some text there
> to better explain the status quo if you think it is needed. Suggest:
>
> “Typically joining a new network requires some form of user action (e.g
> physically plugging in a cable or selecting a network in a OS dialogue) and
> so a user is also implicitly choosing to use the DHCP-provided resolver via
> this action too."
>

The user has no idea that such a DHCP resolver even exists. And you could
say the same thing about the user's choice to install an application with
its own resolver selection logic.


> I can’t think of a mobile or desktop OS that doesn’t allow users to
> override the DHCP provided DNS settings…. but I could text about that in
> section 5.1.1. if you really think it is needed?
>

This isn't about that. AFAICT most major applications also allow you to use
the system resolver choices. Rather, the issue here is the repeated
arguments in this discussion (which you implicitly accept above) that the
current status quo somehow represents user choice whereas an application
choosing its own resolver does not. And both this text and your proposed
text implicitly takes a position on that.


> The point in section 3.5.1.1.2  terms of privacy considerations is that
> any application that uses an application specific DNS setting introduces
> 

Re: [dns-privacy] Datatracker State Update Notice:

[Vittorio Bertola]

> Il 23/01/2020 14:08 Sara Dickinson  ha scritto:
> 
> I don’t disagree that this a desirable feature but since the remit of the 
> document is to describe the current situation, and this option is not 
> available today AFAIK I’m not sure it should be included. I suggested to Ekr 
> that text is added at the start of the second paragraph in this section that 
> says:
> 
> "Such application-specific setting introduce new control points on the end 
> user device for DNS resolution settings in addition to the historically used 
> system settings.”
> 
> Would that address your concern?

Well, at least it mentions the issue, so I'm fine with it, thanks.

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Sara Dickinson]

> On 21 Jan 2020, at 14:46, Vittorio Bertola 
>  wrote:
> 
> 
>> Il 20/01/2020 22:45 Eric Vyncke (evyncke)  ha scritto:
>> 
>> But, as section 3.5.1 ("in the recursive resolvers") raised a lot of 
>> discussions during the first IETF Last Call, and as the authors reacted to 
>> those comments by deep changes in the text, let's have a new IETF Last Call 
>> before proceeding with IESG evaluation.
> 
> First of all, I'd like to thank Sara for all the effort in rewriting a lot of 
> text yet another time to address all the comments. I think the result is 
> good, even if I would have preferred other text on certain things.
> 
> There is only a minor comment that I still have on 3.5.1. The new version has 
> a part about DNS centralization risks, but it only addresses the risks 
> deriving from the ISP market, not the newer ones coming from 
> "application-specific resolver selection", which were mentioned in -03. I 
> have two alternative text proposals to cover this:
> 
> 1) in the bullet list in 3.5.1.1, add another bullet:
> 
> "* popular applications directing DNS traffic by default to specific dominant 
> resolvers"

I’ll add this with a reference to section 3.5.1.1.2

> 
> or 
> 
> 2) in 3.5.1.1.2., last paragraph, just after "increase or decrease user 
> privacy" and before the hyphen, add:
> 
> "and promote or counter centralization”

Sure.

> 
> Given Eric's (not Éric's :-) ) comment on the requirements for user control 
> in 3.5.1.1.2, i.e. that they also apply to the selection of non-encrypted 
> resolvers today, it would be fine for me if they were extended to device/OS 
> resolver configuration in general. In that case, I would plead for the 
> addition of a point regarding the fact that the user should be enabled to 
> configure the resolver for the OS and all the applications at once, in a 
> single place.

I don’t disagree that this a desirable feature but since the remit of the 
document is to describe the current situation, and this option is not available 
today AFAIK I’m not sure it should be included. I suggested to Ekr that text is 
added at the start of the second paragraph in this section that says:

"Such application-specific setting introduce new control points on the end user 
device for DNS resolution settings in addition to the historically used system 
settings.”

Would that address your concern?

> 
> I also have an editorial suggestion: to reduce the nesting of sub-sections in 
> 3.5, perhaps you could break down section 3 into multiple first-level 
> sections and do some renumbering, e.g.
> 
> 3. -> 3.
> 3.1, 3.2, 3.3 -> 4.1, 4.2, 4.3 within "4. Risks in the DNS data"
> 3.4 -> "5. Risks on the wire"
> 3.5 -> "6. Risks in the servers"
> 3.6, 3.7 -> 7.1, 7.2 within "7. Other risks”

I like this suggestion and agree it would make the document structure better - 
thank you, will update.

Sara.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Rescorla]

On Tue, Jan 21, 2020 at 6:46 AM Vittorio Bertola  wrote:

>
> > Il 20/01/2020 22:45 Eric Vyncke (evyncke)  ha
> scritto:
> >
> > But, as section 3.5.1 ("in the recursive resolvers") raised a lot of
> discussions during the first IETF Last Call, and as the authors reacted to
> those comments by deep changes in the text, let's have a new IETF Last Call
> before proceeding with IESG evaluation.
>
> First of all, I'd like to thank Sara for all the effort in rewriting a lot
> of text yet another time to address all the comments. I think the result is
> good, even if I would have preferred other text on certain things.
>
> There is only a minor comment that I still have on 3.5.1. The new version
> has a part about DNS centralization risks, but it only addresses the risks
> deriving from the ISP market, not the newer ones coming from
> "application-specific resolver selection", which were mentioned in -03. I
> have two alternative text proposals to cover this:
>
> 1) in the bullet list in 3.5.1.1, add another bullet:
>
> "* popular applications directing DNS traffic by default to specific
> dominant resolvers"
>
> or
>
> 2) in 3.5.1.1.2., last paragraph, just after "increase or decrease user
> privacy" and before the hyphen, add:
>
> "and promote or counter centralization"
>
> Given Eric's (not Éric's :-) ) comment on the requirements for user
> control in 3.5.1.1.2, i.e. that they also apply to the selection of
> non-encrypted resolvers today, it would be fine for me if they were
> extended to device/OS resolver configuration in general. In that case, I
> would plead for the addition of a point regarding the fact that the user
> should be enabled to configure the resolver for the OS and all the
> applications at once, in a single place.
>

I would not be in favor of this. It's squarely in the zone of controversy.

-Ekr


> I also have an editorial suggestion: to reduce the nesting of sub-sections
> in 3.5, perhaps you could break down section 3 into multiple first-level
> sections and do some renumbering, e.g.
>
> 3. -> 3.
> 3.1, 3.2, 3.3 -> 4.1, 4.2, 4.3 within "4. Risks in the DNS data"
> 3.4 -> "5. Risks on the wire"
> 3.5 -> "6. Risks in the servers"
> 3.6, 3.7 -> 7.1, 7.2 within "7. Other risks"
>
> In any case, I think that we now have a solid document and hope we can
> release it soon.
>
> --
>
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> vittorio.bert...@open-xchange.com
> Office @ Via Treviso 12, 10144 Torino, Italy
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Vittorio Bertola]

> Il 20/01/2020 22:45 Eric Vyncke (evyncke)  ha scritto:
> 
> But, as section 3.5.1 ("in the recursive resolvers") raised a lot of 
> discussions during the first IETF Last Call, and as the authors reacted to 
> those comments by deep changes in the text, let's have a new IETF Last Call 
> before proceeding with IESG evaluation.

First of all, I'd like to thank Sara for all the effort in rewriting a lot of 
text yet another time to address all the comments. I think the result is good, 
even if I would have preferred other text on certain things.

There is only a minor comment that I still have on 3.5.1. The new version has a 
part about DNS centralization risks, but it only addresses the risks deriving 
from the ISP market, not the newer ones coming from "application-specific 
resolver selection", which were mentioned in -03. I have two alternative text 
proposals to cover this:

1) in the bullet list in 3.5.1.1, add another bullet:

"* popular applications directing DNS traffic by default to specific dominant 
resolvers"

or 

2) in 3.5.1.1.2., last paragraph, just after "increase or decrease user 
privacy" and before the hyphen, add:

"and promote or counter centralization"

Given Eric's (not Éric's :-) ) comment on the requirements for user control in 
3.5.1.1.2, i.e. that they also apply to the selection of non-encrypted 
resolvers today, it would be fine for me if they were extended to device/OS 
resolver configuration in general. In that case, I would plead for the addition 
of a point regarding the fact that the user should be enabled to configure the 
resolver for the OS and all the applications at once, in a single place.

I also have an editorial suggestion: to reduce the nesting of sub-sections in 
3.5, perhaps you could break down section 3 into multiple first-level sections 
and do some renumbering, e.g.

3. -> 3.
3.1, 3.2, 3.3 -> 4.1, 4.2, 4.3 within "4. Risks in the DNS data"
3.4 -> "5. Risks on the wire"
3.5 -> "6. Risks in the servers"
3.6, 3.7 -> 7.1, 7.2 within "7. Other risks"

In any case, I think that we now have a solid document and hope we can release 
it soon.

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Rescorla]

+last-call

On Mon, Jan 20, 2020 at 2:37 PM Eric Rescorla  wrote:

> Review comments attached:
>
>
> COMMENTS
> S 3.1.
> >  described above, and may not have any confidentiality requirements..
> >  However, the same is not true of a single transaction or a sequence
> >  of transactions; that transaction is not / should not be public.  A
> >  typical example from outside the DNS world is: the web site of
> >  Alcoholics Anonymous is public; the fact that you visit it should
> not
> >  be.
>
> Well, technically what you want to conceal is the origin of the
> transaction or its linkage to other transactions. The existence of the
> query for that A record isn't secret.
>
>
>
>
>
> S 3.4.2.
> >  fingerprint [2] values can be used to fingerprint client OS's or
> that
> >  various techniques can be used to de-NAT DNS queries dns-de-nat [3].
> >
> >  Note that even when using encrypted transports the use of clear text
> >  transport options to decrease latency can provide correlation of a
> >  users' connections e.g.  using TCP Fast Open [RFC7413] with TLS 1.2.
>
> Why does this say TLS 1.2? Any use of TFO will have the same
> properties.
>
> Perhaps you are thinking of TLS session tickets here?
>
>
>
>
> S 3.4.2.
> >  services available.  Given this, the choice of a user to configure a
> >  single resolver (or a fixed set of resolvers) and an encrypted
> >  transport to use in all network environments can actually serve to
> >  identify the user as one that desires privacy and can provide an
> >  added mechanism to track them as they move across network
> >  environments.
>
> I don't understand this paragraph. It's not the choice of specific
> resolvers that leaks data, but the choice to turn on encryption, In
> fact, from an identification purpose, the more resolvers that support
> encrypted transport, the better signal this is.
>
>
> S 3.4.2.
> >  identify the user as one that desires privacy and can provide an
> >  added mechanism to track them as they move across network
> >  environments.
> >
> >  Implementations that support encrypted transports also commonly re-
> >  use sessions for multiple DNS queries to optimize performance (e.g..
>
> Note: session is a technical term in TLS that refers to the
> association not the connection. I would say "connection"
>
>
> S 3.5.1.1.2.
> >
> >  o  communicate clearly the change in default to users
> >
> >  o  provide configuration options to change the default
> >
> >  o  provide configuration options to always use the system resolver
>
> I get that you think this is neutral, but all of this is equally true
> about dynamic discovery via DHCP, it's just that that's the status
> quo, so you don't notice it. In this context, this text is tendentious.
>
>
> S 3.5.1.1.2.
> >
> >  Application-specific changes to default destinations for users' DNS
> >  queries might increase or decrease user privacy - it is highly
> >  dependent on the network context and the application-specific
> >  default.  This is an area of active debate and the IETF is working
> on
> >  a number of issues related to application-specific DNS settings.
>
> This, too, could be said about the current situation.
>
> On Mon, Jan 20, 2020 at 1:47 PM Eric Vyncke (evyncke) 
> wrote:
>
>> Thanks to Sara and Stéphane for the -04 revised I-D.
>>
>> After reading the -04, I think that most of the IETF Last Call comments
>> are addressed (and consensus needs to be balanced -- even for informational
>> document) and that the document sticks to facts.
>>
>> But, as section 3.5.1 ("in the recursive resolvers") raised a lot of
>> discussions during the first IETF Last Call, and as the authors reacted to
>> those comments by deep changes in the text, let's have a new IETF Last Call
>> before proceeding with IESG evaluation.
>>
>> Again, thank you to the reviewers and the authors
>>
>> Regards,
>>
>> -éric
>>
>>
>> On 20/01/2020, 22:34, "IETF Secretariat" <
>> ietf-secretariat-re...@ietf.org> wrote:
>>
>> IESG state changed:
>>
>> New State: Last Call Requested
>>
>> (The previous state was Waiting for AD Go-Ahead::AD Followup)
>>
>> The previous last call raised several points. The authors have worked
>> on those points and this new informational IETF draft has substantive
>> changes; enough to go trigger a new IETF Last Call.
>>
>> -éric
>>
>> Datatracker URL:
>> https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/
>>
>>
>>
>> ___
>> dns-privacy mailing list
>> dns-privacy@ietf.org
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Rescorla]

Review comments attached:


COMMENTS
S 3.1.
>  described above, and may not have any confidentiality requirements.
>  However, the same is not true of a single transaction or a sequence
>  of transactions; that transaction is not / should not be public.  A
>  typical example from outside the DNS world is: the web site of
>  Alcoholics Anonymous is public; the fact that you visit it should not
>  be.

Well, technically what you want to conceal is the origin of the
transaction or its linkage to other transactions. The existence of the
query for that A record isn't secret.





S 3.4.2.
>  fingerprint [2] values can be used to fingerprint client OS's or that
>  various techniques can be used to de-NAT DNS queries dns-de-nat [3].
>
>  Note that even when using encrypted transports the use of clear text
>  transport options to decrease latency can provide correlation of a
>  users' connections e.g.  using TCP Fast Open [RFC7413] with TLS 1.2.

Why does this say TLS 1.2? Any use of TFO will have the same
properties.

Perhaps you are thinking of TLS session tickets here?




S 3.4.2.
>  services available.  Given this, the choice of a user to configure a
>  single resolver (or a fixed set of resolvers) and an encrypted
>  transport to use in all network environments can actually serve to
>  identify the user as one that desires privacy and can provide an
>  added mechanism to track them as they move across network
>  environments.

I don't understand this paragraph. It's not the choice of specific
resolvers that leaks data, but the choice to turn on encryption, In
fact, from an identification purpose, the more resolvers that support
encrypted transport, the better signal this is.


S 3.4.2.
>  identify the user as one that desires privacy and can provide an
>  added mechanism to track them as they move across network
>  environments.
>
>  Implementations that support encrypted transports also commonly re-
>  use sessions for multiple DNS queries to optimize performance (e.g.

Note: session is a technical term in TLS that refers to the
association not the connection. I would say "connection"


S 3.5.1.1.2.
>
>  o  communicate clearly the change in default to users
>
>  o  provide configuration options to change the default
>
>  o  provide configuration options to always use the system resolver

I get that you think this is neutral, but all of this is equally true
about dynamic discovery via DHCP, it's just that that's the status
quo, so you don't notice it. In this context, this text is tendentious.


S 3.5.1.1.2.
>
>  Application-specific changes to default destinations for users' DNS
>  queries might increase or decrease user privacy - it is highly
>  dependent on the network context and the application-specific
>  default.  This is an area of active debate and the IETF is working on
>  a number of issues related to application-specific DNS settings.

This, too, could be said about the current situation.

On Mon, Jan 20, 2020 at 1:47 PM Eric Vyncke (evyncke) 
wrote:

> Thanks to Sara and Stéphane for the -04 revised I-D.
>
> After reading the -04, I think that most of the IETF Last Call comments
> are addressed (and consensus needs to be balanced -- even for informational
> document) and that the document sticks to facts.
>
> But, as section 3.5.1 ("in the recursive resolvers") raised a lot of
> discussions during the first IETF Last Call, and as the authors reacted to
> those comments by deep changes in the text, let's have a new IETF Last Call
> before proceeding with IESG evaluation.
>
> Again, thank you to the reviewers and the authors
>
> Regards,
>
> -éric
>
>
> On 20/01/2020, 22:34, "IETF Secretariat" 
> wrote:
>
> IESG state changed:
>
> New State: Last Call Requested
>
> (The previous state was Waiting for AD Go-Ahead::AD Followup)
>
> The previous last call raised several points. The authors have worked
> on those points and this new informational IETF draft has substantive
> changes; enough to go trigger a new IETF Last Call.
>
> -éric
>
> Datatracker URL:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/
>
>
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Vyncke (evyncke)]

Thanks to Sara and Stéphane for the -04 revised I-D. 

After reading the -04, I think that most of the IETF Last Call comments are 
addressed (and consensus needs to be balanced -- even for informational 
document) and that the document sticks to facts.

But, as section 3.5.1 ("in the recursive resolvers") raised a lot of 
discussions during the first IETF Last Call, and as the authors reacted to 
those comments by deep changes in the text, let's have a new IETF Last Call 
before proceeding with IESG evaluation.

Again, thank you to the reviewers and the authors

Regards,

-éric


On 20/01/2020, 22:34, "IETF Secretariat"  
wrote:

IESG state changed:

New State: Last Call Requested

(The previous state was Waiting for AD Go-Ahead::AD Followup)

The previous last call raised several points. The authors have worked on 
those points and this new informational IETF draft has substantive changes; 
enough to go trigger a new IETF Last Call.

-éric

Datatracker URL: 
https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/



___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IESG state changed:

New State: Last Call Requested

(The previous state was Waiting for AD Go-Ahead::AD Followup)

The previous last call raised several points. The authors have worked on those 
points and this new informational IETF draft has substantive changes; enough to 
go trigger a new IETF Last Call.

-éric

Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IESG state changed:

New State: Waiting for AD Go-Ahead::Revised I-D Needed

(The previous state was Waiting for AD Go-Ahead)

Revised I-D needed to address relevant comments received during the last call.

Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IESG state changed:

New State: Waiting for AD Go-Ahead

(The previous state was Waiting for Writeup)

Waiting for authors' reply on Martin Thomson's review 
https://mailarchive.ietf.org/arch/msg/dns-privacy/KGOMjN-W3_wywvZUZ12j-sAC6ps

Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IANA review state changed to "IANA OK - No Actions Needed"
Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IESG state changed:

New State: Last Call Requested

(The previous state was AD Evaluation::AD Followup)


Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IESG state changed:

New State: AD Evaluation::Revised I-D Needed

(The previous state was AD Evaluation)

Some minor comments/nits sent by email to the authors. Revision is expected to 
have a clean Last Call.

Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IESG state changed:

New State: AD Evaluation

(The previous state was Publication Requested)


Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IANA action state changed to "No IC"
Datatracker URL: 
https://datatracker.ietf.org/doc/draft-ietf-dprive-padding-policy/

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Datatracker State Update Notice:

[IETF Secretariat]

IANA action state changed to "In Progress"
Datatracker URL: 
https://datatracker.ietf.org/doc/draft-ietf-dprive-padding-policy/

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy