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
