Subject: Re: [dns-privacy] Last Call: <draft-ietf-dprive-rfc7626-bis-03.txt> (DNS Privacy Considerations) to Informational RFC

From: S Moonesamy <[email-masked]>
Date: Wed, 01 Jan 2020 22:45:58 -0800

Hello,

There are currently four (IETF) working groups focused on DNS with 
three of them having privacy as part of their charter.  I read 
draft-ietf-dprive-rfc7626-bis-03 as I was looking for a document 
which might be related to those topics.

Section 1 of the draft has a tutorial of how DNS works.  What is the 
audience for this draft?

Section 3.1 of the draft discusses about the claim that "the data in 
the DNS is public".  The claim is supported [1] by one of the authors 
of the draft.  The draft states that the claim makes sense.  What is 
the meaning of the "data in the DNS"?  Does "is public" mean that the 
"data" is not confidential?

Section 3.2 discusses what a user does and use a DNS query related to 
email as an example.  Is the MUA expected to validated the MX RR or 
is it the role of the MSA?

Section 3.4.1 discusses the lack of confidentiality in the design of 
DNSSEC and equates privacy-aware with "secured against 
surveillance".  Mixing the pervasive monitoring and privacy aspects 
creates ambiguity.  For example, encrypting all the entire DNS 
communication chain with adequate security mechanisms could mitigate 
pervasive monitoring concerns.  However, that does not address 
privacy concerns as there is still entities which are able to collect 
and process those DNS queries for secondary purposes.

The choice of resolvers was previously made by the network on which 
the user was connected.  Recently, the Internet Engineering Steering 
Group approved the standardization of a mechanism so that the choice 
can be made by a web browser.  The data from the DNS query is, with 
some exceptions, automatically transferred to a foreign 
jurisdiction.  The draft mentions in Section 3.5.1.1 that the 
entities running networks might have a strong, medium, or weak 
privacy policy.  However, it misses a crucial aspect  with respect to 
privacy policies, which is the redress mechanism available to the user.

Section 3.5.1.3 states that user privacy can also be at risk if the 
network operator blocks access to some remote recursive server.  It 
could be argued that it might be a filtering (or censorship) 
technique.  However, it does not have an impact on user privacy 
unless there is an identifier which can be traced back to the user.

If I understood Section 3.5.1.5.2. correctly, the move to DNS over 
HTTPS created more privacy issues because HTTPS functionality was 
favored at the expense of privacy.

Section 3.6 of the draft states that the IAB privacy and security 
program has some work in progress.  Given that it has been over four 
years, could an update be provided about that work in progress?

Section 5 discusses legalities within a European Union context and 
concluded that there are no specific laws for DNS data in any 
country.  Did the working group conduct a worldwide study to find 
evidence of that?

Regards,
S. Moonesamy

1. http://r.elandsys.com/r/32470

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 9 Jan 2020 16:44:45 +0100

On Wed, Jan 01, 2020 at 10:45:58PM -0800,
 S Moonesamy <[email-masked]> wrote 
 a message of 63 lines which said:

> There are currently four (IETF) working groups focused on DNS with three of
> them having privacy as part of their charter.

doh, dnssd and dprive (plus dnsop)?

> Section 1 of the draft has a tutorial of how DNS works.  What is the

People (mostly at the IETF) interested by DNS privacy. When preparing
RFC 7626, we saw that many IETF participants had fuzzy (and sometimes
wrong) ideas about the DNS so this introduction seems a good idea.

> Section 3.1 of the draft discusses about the claim that "the data in the DNS
> is public".  The claim is supported [1] by one of the authors of the
> draft.

It is indeed an important tenet of the draft (as it was for RFC 7626).

> The draft states that the claim makes sense.  What is the meaning of the
> "data in the DNS"?

I'm confused. Is it a real question? Anyway, it proves that a tutorial
on the DNS is useful :-) So, "data" is the content of the Answer,
Additional and Authority sections in the answer. RFC 7626, section
2.1.

> the user was connected.

No. (If you say Yes, please quote the relevant RFC.) DNS is a
protocol, the way a machine provisions its resolver(s) is out of scope.

> Recently, the Internet Engineering Steering Group approved the
> standardization of a mechanism so that the choice can be made by a
> web browser.

That's a very serious misrepresentation of DoH. Counter-example:
Google Chrome did DNS resolution with UDP, a long time ago. 

> The data from the DNS query is, with some exceptions, automatically
> transferred to a foreign jurisdiction.

Again, it seems you don't know the difference between a protocol and
an implementation.

---

From: S Moonesamy <[email-masked]>
Date: Thu, 09 Jan 2020 08:48:40 -0800

Hi Stephane, Brian,
>doh, dnssd and dprive (plus dnsop)?

Yes.

>wrong) ideas about the DNS so this introduction seems a good idea.

Ok.

>Additional and Authority sections in the answer. RFC 7626, section

It was an actual question.  Thank you for clarifying that it only 
refers to the Answer and other sections.  I also asked about the 
meaning of "is public".  Would it be possible for the working group 
to provide feedback about that?

>protocol, the way a machine provisions its resolver(s) is out of scope.

The Abstract of the draft states that it describes the privacy issues 
associated with the use of the DNS by Internet users.  Section 1 of 
the draft states the use of RFC 1034 and RFC 1035 has many privacy 
implications.  If I understood the above, the draft is only about 
what is in RFC 1034 and RFC 1035 and everything else is out of 
scope.  Is that correct?

>Google Chrome did DNS resolution with UDP, a long time ago.

I mentioned web browser and not Google Chrome.  I tested a web 
browser which is not Google Chrome.  The DNS queries were sent to the 
local resolver.  I did another test with Firefox.  The DNS queries 
were also sent to the local resolver.

>Again, it seems you don't know the difference between a protocol and

Ok.

Could the Working Group please see the questions [1] about Section 
3.2 and Section 5?

Regards,
S. Moonesamy

1. 
https://mailarchive.ietf.org/arch/msg/dns-privacy/lS2BdqksRMwKYgg8McnEHEDwhlc

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Jan 2020 09:51:50 -0800

> were also sent to the local resolver.

I think you're misunderstanding Stephane.

You wrote:
"The choice of resolvers was previously made by the network on which
the user was connected.  Recently, the Internet Engineering Steering
Group approved the standardization of a mechanism so that the choice
can be made by a web browser. "

This isn't correct. Web browsers have *always* been able to choose their
own resolver because DNS is just UDP packets, which the browser is quite
capable of sending (e.g., QUIC, WebRTC). Historically, browsers have
chosen to use the system resolver which customarily gets its choice of
resolver from the network, however, Chrome, at least, for some time has
done DNS resolution itself, albeit using the same resolver as the system
resolver used. However, they could easily have chosen to use 8.8.8.8
(or some other resolver) instead.

The point here is that DoH is orthogonal to the question of which resolver
you use.

-Ekr

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 23 Jan 2020 13:15:04 +0000

> On 2 Jan 2020, at 06:45, S Moonesamy <[email-masked]> wrote:
> 
> Hello,
> 
> There are currently four (IETF) working groups focused on DNS with three of them having privacy as part of their charter.  I read draft-ietf-dprive-rfc7626-bis-03 as I was looking for a document which might be related to those topics.

Comments here are based on the content of the -04 draft. 

> 
> Section 1 of the draft has a tutorial of how DNS works.  What is the audience for this draft?
> 
> Section 3.1 of the draft discusses about the claim that "the data in the DNS is public".  The claim is supported [1] by one of the authors of the draft.  The draft states that the claim makes sense.  What is the meaning of the "data in the DNS"?  Does "is public" mean that the "data" is not confidential?

Both previously answered by Stephane.

> 
> Section 3.2 discusses what a user does and use a DNS query related to email as an example.  Is the MUA expected to validated the MX RR or is it the role of the MSA?

I think questions of validation are out of scope for this draft.

> 
> Section 3.4.1 discusses the lack of confidentiality in the design of DNSSEC and equates privacy-aware with "secured against surveillance".  Mixing the pervasive monitoring and privacy aspects creates ambiguity.  For example, encrypting all the entire DNS communication chain with adequate security mechanisms could mitigate pervasive monitoring concerns.  However, that does not address privacy concerns as there is still entities which are able to collect and process those DNS queries for secondary purposes.

The draft contains sections on both the wire encryption (3.4) and handling of data in the servers (3.5) which between them cover these two aspects. Do you have a specific suggestion for changes to the draft?

> 
> The choice of resolvers was previously made by the network on which the user was connected.  Recently, the Internet Engineering Steering Group approved the standardization of a mechanism so that the choice can be made by a web browser.  The data from the DNS query is, with some exceptions, automatically transferred to a foreign jurisdiction.  The draft mentions in Section 3.5.1.1 that the entities running networks might have a strong, medium, or weak privacy policy.  However, it misses a crucial aspect  with respect to privacy policies, which is the redress mechanism available to the user.

Since such mechanisms would vary at least by region and certainly by organisation so I’m not sure what can be said here. Do you have specific text to suggest on this topic? 

> 
> Section 3.5.1.3 states that user privacy can also be at risk if the network operator blocks access to some remote recursive server.  It could be argued that it might be a filtering (or censorship) technique.  However, it does not have an impact on user privacy unless there is an identifier which can be traced back to the user.

Section 3.5.1.3 states: 

“User privacy can also be at risk if there is blocking (by local
   network operators or more general mechanisms) of access to remote
   recursive servers that offer encrypted transports when the local
   resolver does not offer encryption and/or has very poor privacy
   policies."

and “This is a form of Rendezvous-Based Blocking as described in Section 4.3 of [RFC7754].”

which I think cover both of your issues. Otherwise, please suggest text.

> 
> If I understood Section 3.5.1.5.2. correctly, the move to DNS over HTTPS created more privacy issues because HTTPS functionality was favored at the expense of privacy.

To quote from Section 3.5.1.5.2:
“Utilizing the full set of HTTP features enables DoH to be more than an HTTP tunnel, but it is at the cost of opening up implementations to the full set of privacy considerations of HTTP."

> 
> Section 3.6 of the draft states that the IAB privacy and security program has some work in progress.  Given that it has been over four years, could an update be provided about that work in progress?

Looking back, this text was introduced into the original I-D before RFC7624 was published and wasn’t updated. Suggest:

OLD: “The IAB privacy and security program also have a work in progress [RFC7624] that considers such inference-based attacks in a more general framework.”

OLD: “The IAB privacy and security program has also produced [RFC7624] that considers such inference-based attacks in a more general framework."

> 
> Section 5 discusses legalities within a European Union context and concluded that there are no specific laws for DNS data in any country.  Did the working group conduct a worldwide study to find evidence of that?

The text says “to our knowledge’; no DPRIVE or IETF review comment to date (or errata to RFC7626) has contradicted this statement so I think it is a fair representation of the community knowledge on this matter. If you are aware of such a law please suggest text. 

Best regards

Sara.

---

From: S Moonesamy <[email-masked]>
Date: Thu, 23 Jan 2020 06:11:08 -0800

Dear Sara,
At 05:15 AM 23-01-2020, Sara Dickinson wrote:
> > Section 3.2 discusses what a user does and use a DNS query 
> related to email as an example.  Is the MUA expected to validated 
> the MX RR or is it the role of the MSA?
>

Apologies for not explaining this correctly.  The draft is described 
as a document about the use of DNS.  Section 3.2 has the following: 
"It gives information about what the user does ("What are the MX 
records of example.net?" means he probably wants to send email to 
someone at example.net ..."  My question was about that DNS 
query.  Could you or the WG Chairs please explain why the question 
which I asked is out of scope for this draft?

>Looking back, this text was introduced into the original I-D before 
>RFC7624 was published and wasn't updated. Suggest:
>
>OLD: The IAB privacy and security program also have a work in 
>progress [RFC7624] that considers such inference-based attacks in a 
>more general framework.
>
>OLD: The IAB privacy and security program has also produced 
>[RFC7624] that considers such inference-based attacks in a more 
>general framework."

I gather that you meant "NEW" for the second part.  I am okay with that text.

>The text says "to our knowledge"; no DPRIVE or IETF review comment 
>to date (or errata to RFC7626) has contradicted this statement so I 
>think it is a fair representation of the community knowledge on this 
>matter. If you are aware of such a law please suggest text.

I asked whether there was a study.  According to the above, it is 
what the DPRIVE Working Group believes even though there wasn't any 
study.  I would like to thank you for the response as it addresses my question.

Regards,
S. Moonesamy

---

From: Brian Haberman <[email-masked]>
Date: Thu, 23 Jan 2020 09:35:01 -0500

Hi SM,

On 1/23/20 9:11 AM, S Moonesamy wrote:
>> > Section 3.2 discusses what a user does and use a DNS query related
>> to email as an example.  Is the MUA expected to validated the MX RR or
> Apologies for not explaining this correctly.  The draft is described as
> a document about the use of DNS.  Section 3.2 has the following: "It
> gives information about what the user does ("What are the MX records of
> example.net?" means he probably wants to send email to someone at
> example.net ..."  My question was about that DNS query.  Could you or
> the WG Chairs please explain why the question which I asked is out of
> scope for this draft?
> 

I believe the text in question is:

   The QNAME is the full name sent by the user.  It gives information
   about what the user does ("What are the MX records of example.net?"
   means he probably wants to send email to someone at example.net,
   which may be a domain used by only a few persons and is therefore
   very revealing about communication relationships).

Given that the section is focused on the risk of the data included in
the DNS request, I interpret the above to be describing what privacy
risks exist by simply having the DNS payload be visible to observers. In
this case, an observer can see that a particular IP address is looking
up DNS info for a domain that may only be accessed by a small number people.

The document does not purport to explain how various
applications/services should/could perform any type of "validation" on
the returned information. I am also unclear on where the concept of
validation came out of that text.

Regards,
Brian

---

From: Sara Dickinson <[email-masked]>
Date: Fri, 24 Jan 2020 14:44:51 +0000

> On 23 Jan 2020, at 14:11, S Moonesamy <[email-masked]> wrote:
> 
> Dear Sara,
> Apologies for not explaining this correctly.  The draft is described as a document about the use of DNS.  Section 3.2 has the following: "It gives information about what the user does ("What are the MX records of example.net?" means he probably wants to send email to someone at example.net ..."  My question was about that DNS query.  Could you or the WG Chairs please explain why the question which I asked is out of scope for this draft?

Thanks to Brian for his explanation on this point which I agree with.

> 
>> Looking back, this text was introduced into the original I-D before RFC7624 was published and wasn't updated. Suggest:
>> 
>> OLD: The IAB privacy and security program also have a work in progress [RFC7624] that considers such inference-based attacks in a more general framework.
>> 
>> OLD: The IAB privacy and security program has also produced [RFC7624] that considers such inference-based attacks in a more general framework."
> 

Yes :-)

> 
>> The text says "to our knowledge"; no DPRIVE or IETF review comment to date (or errata to RFC7626) has contradicted this statement so I think it is a fair representation of the community knowledge on this matter. If you are aware of such a law please suggest text.
> 
> I asked whether there was a study.  According to the above, it is what the DPRIVE Working Group believes even though there wasn't any study.  I would like to thank you for the response as it addresses my question.

Ah, you were asking if there was a specific citation that could be included… No, not to my knowledge. 

Thanks for your response.

Sara.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 24 Jan 2020 10:37:54 -0800

Hi Brian,
>Thanks to Brian for his explanation on this point which I agree with.

Thanks, I see an explanation at 
https://mailarchive.ietf.org/arch/msg/dns-privacy/tr6ZNtxgScyDWwwyy3pUIpJxmY0 
I used the word "validation" as it would be generally understood in 
(IETF) discussions about mail protocols.  From a DNS perspective, it 
would be a DNS query.  Mail User Agents (MUA) generally do not 
perform DNS queries on the domain part of an email address.  The only 
exception I can think of is "direct-to-MX".  It is unlikely that 
sending an email directly to a mail server (identified by the MX RR) 
would work as outgoing TCP port 25 is usually blocked by Internet 
Service Providers.  In terms of IETF specification, the MUA sumbits 
email to a MSA (RFC 6409).  The DNS queries are intended to be 
performed by the MSA (not the MUA).

In my opinion, the case made in the second paragraph of Section 3.2 
does not match how the code works on the Internet.  I prefer to move 
on instead of pushing back on this issue as I spent more than enough 
effort on it.

For what it is worth, I preferred not to get into a discussion about 
the Introduction section of the draft.  If I am ever asked about the 
text, I will say that I disagreed with it as it is like looking down 
on Internet users ...

Regards,
S. Moonesamy