[dns-privacy] Telechat update notice:

[IETF Secretariat]

Telechat date has been changed to 2020-04-09 from 2020-03-12
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:

[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] Intdir telechat review of draft-ietf-dprive-rfc7626-bis-04

[Eric Vyncke (evyncke)]

Merci very much Jean-Michel, I am sure that the authors will take this into 
account before submitting a revised I-D before the evaluation by the IESG

-éric

-Original Message-
From: Jean-Michel Combes via Datatracker 
Reply-To: Jean-Michel Combes 
Date: Monday, 9 March 2020 at 21:30
To: "int-...@ietf.org" 
Cc: "last-c...@ietf.org" , "dns-privacy@ietf.org" 
, "draft-ietf-dprive-rfc7626-bis@ietf.org" 

Subject: Intdir telechat review of draft-ietf-dprive-rfc7626-bis-04
Resent-From: 
Resent-To: , , 
, , Eric Vyncke 
, Suresh Krishnan , , 
Brian Haberman , 
Resent-Date: Monday, 9 March 2020 at 21:29

Reviewer: Jean-Michel Combes
Review result: Ready with Issues

Hi,

Please find my review, as member of the INT Area Directorate, of the 
following
document:

dprive S. Bortzmeyer
Internet-Draft AFNIC
Obsoletes: 7626 (if approved)   S. Dickinson
Intended status: InformationalSinodun IT
Expires: July 19, 2020  January 16, 2020

   DNS Privacy Considerations
draft-ietf-dprive-rfc7626-bis-04



1.  Introduction



   Let us begin with a simplified reminder of how the DNS works (See
   also [RFC8499]).  A client, the stub resolver, issues a DNS query to
   a server, called the recursive resolver (also called caching resolver
   or full resolver or recursive name server).  Let's use the query
   "What are the  records for www.example.com?" as an example.  
   is the QTYPE (Query Type), and www.example.com is the QNAME (Query
   Name).  (The description that follows assumes a cold cache, for
   instance, because the server just started.)  The recursive resolver
   will first query the root name servers.  In most cases, the root name
   servers will send a referral.  In this example, the referral will be
   to the .com name servers.  The resolver repeats the query to one of
   the .com name servers.  The .com name servers, in turn, will refer to
   the example.com name servers.  The example.com name server will then
   return the answer.  The root name servers, the name servers of .com,
   and the name servers of example.com are called authoritative name
   servers.  It is important, when analyzing the privacy issues, to
   remember that the question asked to all these name servers is always
   the original question, not a derived question.  The question sent to
   the root name servers is "What are the  records for
   www.example.com?", not "What are the name servers of .com?".  By
   repeating the full question, instead of just the relevant part of the
   question to the next in line, the DNS provides more information than
   necessary to the name server.  In this simplified description,
   recursive resolvers do not implement QNAME minimization as described
   in [RFC7816], which will only send the relevant part of the question
   to the upstream name server.


IMHO, that would be clearer to split the previous paragraph into 2 
paragraphs:
- one explaining the general DNS process
- one showing the privacy issue related to the fact the question is not 
derived
BTW, the construction of the end of the previous paragraph suggests that
question derivation and QNAME minimization are two different things. 



   At the time of writing, almost all this DNS traffic is currently sent
   in clear (i.e., unencrypted).  However there is increasing deployment
   of DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484],
   particularly in mobile devices, browsers, and by providers of anycast
   recursive DNS resolution services.  There are a few cases where there
   is some alternative channel encryption, for instance, in an IPsec VPN
   tunnel, at least between the stub resolver and the resolver.


IPsec: a reference is missing.




   o  Tertiary requests: these are the additional requests performed by
  the DNS system itself.  For instance, if the answer to a query is
  a referral to a set of name servers, and the glue records are not
  returned, the resolver will have to do additional requests to turn
  the name servers' names into IP addresses.  Similarly, even if
  glue records are returned, a careful recursive server will do
  tertiary requests to verify the IP addresses of those records.


“glue records”: IMHO, either a reference or a definition is needed.




2.  Scope

   This document focuses mostly on the study of privacy risks for the
   end user (the one performing DNS 

[dns-privacy] Intdir telechat review of draft-ietf-dprive-rfc7626-bis-04

[Jean-Michel Combes via Datatracker]

Reviewer: Jean-Michel Combes
Review result: Ready with Issues

Hi,

Please find my review, as member of the INT Area Directorate, of the following
document:

dprive S. Bortzmeyer
Internet-Draft AFNIC
Obsoletes: 7626 (if approved)   S. Dickinson
Intended status: InformationalSinodun IT
Expires: July 19, 2020  January 16, 2020

   DNS Privacy Considerations
draft-ietf-dprive-rfc7626-bis-04



1.  Introduction



   Let us begin with a simplified reminder of how the DNS works (See
   also [RFC8499]).  A client, the stub resolver, issues a DNS query to
   a server, called the recursive resolver (also called caching resolver
   or full resolver or recursive name server).  Let's use the query
   "What are the  records for www.example.com?" as an example.  
   is the QTYPE (Query Type), and www.example.com is the QNAME (Query
   Name).  (The description that follows assumes a cold cache, for
   instance, because the server just started.)  The recursive resolver
   will first query the root name servers.  In most cases, the root name
   servers will send a referral.  In this example, the referral will be
   to the .com name servers.  The resolver repeats the query to one of
   the .com name servers.  The .com name servers, in turn, will refer to
   the example.com name servers.  The example.com name server will then
   return the answer.  The root name servers, the name servers of .com,
   and the name servers of example.com are called authoritative name
   servers.  It is important, when analyzing the privacy issues, to
   remember that the question asked to all these name servers is always
   the original question, not a derived question.  The question sent to
   the root name servers is "What are the  records for
   www.example.com?", not "What are the name servers of .com?".  By
   repeating the full question, instead of just the relevant part of the
   question to the next in line, the DNS provides more information than
   necessary to the name server.  In this simplified description,
   recursive resolvers do not implement QNAME minimization as described
   in [RFC7816], which will only send the relevant part of the question
   to the upstream name server.


IMHO, that would be clearer to split the previous paragraph into 2 paragraphs:
- one explaining the general DNS process
- one showing the privacy issue related to the fact the question is not derived
BTW, the construction of the end of the previous paragraph suggests that
question derivation and QNAME minimization are two different things. 



   At the time of writing, almost all this DNS traffic is currently sent
   in clear (i.e., unencrypted).  However there is increasing deployment
   of DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484],
   particularly in mobile devices, browsers, and by providers of anycast
   recursive DNS resolution services.  There are a few cases where there
   is some alternative channel encryption, for instance, in an IPsec VPN
   tunnel, at least between the stub resolver and the resolver.


IPsec: a reference is missing.




   o  Tertiary requests: these are the additional requests performed by
  the DNS system itself.  For instance, if the answer to a query is
  a referral to a set of name servers, and the glue records are not
  returned, the resolver will have to do additional requests to turn
  the name servers' names into IP addresses.  Similarly, even if
  glue records are returned, a careful recursive server will do
  tertiary requests to verify the IP addresses of those records.


“glue records”: IMHO, either a reference or a definition is needed.




2.  Scope

   This document focuses mostly on the study of privacy risks for the
   end user (the one performing DNS requests).  We consider the risks of
   pervasive surveillance [RFC7258] as well as risks coming from a more
   focused surveillance.


>From my point of view, but maybe I am wrong, this document is the “Problem
Statement” document regarding DNS Privacy mechanisms. If so, I regret that
there is no text about impact(s), in a security context, when privacy policy
(e.g., DoT, DoH) is deployed. Please, find more comments on such a point inside
Security Considerations section. 



3.2.  Data in the DNS Request



   For the communication between the stub resolver and the recursive
   resolver, the source IP address is the address of the user's machine.
   Therefore, all the issues and warnings about collection of IP
   addresses apply here.  For the communication between the recursive
   resolver and the authoritative name servers, the source IP address
   has a different meaning; it does not have the same status as the
   source address in an HTTP connection.  It is typically 

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