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

[Eric Rescorla <[e-mail]>]

On Thu, Jan 9, 2020 at 10:03 AM Sara Dickinson <[e-mail]> wrote:

>
>
> On 7 Jan 2020, at 22:51, Eric Rescorla <[e-mail]> wrote:
>
>
>
> On Tue, Jan 7, 2020 at 10:38 AM Sara Dickinson <[e-mail]> wrote:
>
>>
>>
>> On 31 Dec 2019, at 14:45, Eric Rescorla <[e-mail]> wrote:
>>
>>
>>
> <snip>
>
>
>>
>>> Also on linkability and identification:
>>>
>>> Certain configuration options for encrypted transports could also in
>>> principle fingerprint a user or client application.
>>>
>>>
>>> Though there are definitely ways in which the listed options contribute
>>> to fingerprinting, the paragraph talks about session resumption, where the
>>> concern is primarily linkability.  Mixing these concepts only serves to
>>> confuse rather than enlighten.
>>>
>>> When it comes to fingerprinting, it's important to distinguish between
>>> an ability to identify the software in use (Windows vs. Linux, Safari vs.
>>> Chrome) and the ability to distinguish different users.  The text here
>>> conflates these notions in an unhelpful fashion. The fingerprinting
>>> highlighted is a result of characteristics inherent to the software, not
>>> user-specific details.
>>>
>>>
>>> For the most part, we (as protocol designers) accept that distinguishing
>>> software is possible and we don't generally attempt to erase differences
>>> that only serve to reinforce those signals. Suppressing differences in wire
>>> image across implementations generally runs counter to the desire for
>>> diversity in implementation choices.  This text - perhaps unintentionally -
>>> takes the somewhat sensational position that distinguishing between FreeBSD
>>> and Solaris is as relevant as the sort of fingerprinting that might be used
>>> to isolate individuals.  It does that by concentrating on choices that are
>>> usually made by implementations not individuals.
>>>
>>> This is where a clear recognition of the distinction between
>>> implementation choices and how implementations represent (or maybe don't
>>> represent, if that is the way you feel) the choices of individuals requires
>>> a little more care.  I don't know how easy it is to engage on that topic
>>> without also engaging with the current debate though.
>>>
>>>
>>> Suggest:
>>>
>>> OLD:
>>> “Users of encrypted transports are also highly likely to re-use sessions
>>> for multiple DNS queries to optimize performance (e.g. via DNS pipelining
>>> or HTTPS multiplexing). Certain configuration options for encrypted
>>> transports could also in principle fingerprint a user or client
>>> application.  For example: …."
>>>
>>> NEW:
>>> “Implementations that support encrypted transports are also highly
>>> likely to re-use sessions for multiple DNS queries to optimize performance
>>> (e.g. via DNS pipelining or HTTPS multiplexing). Default configuration
>>> options for encrypted transports could in principle fingerprint a specific
>>> client application. For example:…
>>>
>>
>> I don't generally think that documents like this ought to predict how
>> implementers will behave, so I would remove this text entirely.
>>
>>
>> But one of the points of this document is to describe the actual use of
>> DNS so discussing implementation behaviour seems within scope. Given many
>> of the implementations of DoT are done by DNS developers who might be
>> implementing TLS for the first time highlighting potential privacy
>> considerations with such implementation choices also seems relevant.
>>
>
> There are two problems here:
>
> 1. That you are making predictions about what people will do and that
> those preductions are unsupported by evidence. That needs to go.
>
>
> If you are talking about the specific text above - are you saying you
> don’t believe any existing implementations of encrypted DNS transports
> re-use sessions? If so, I can add the list of ones that do to the document.
> Or you believe they all use the same default configuration options?  If not
> what is the specific prediction you mean?
>

Your text says "highly likely". I'm sure that *some* implementation does,
but that doesn't make it highly likely unless you intend to say "it is
highly likely that some implementation will", which seems silly.


> 2. That you are covering material that is already better covered in 8484,
> so why are you duplicating it?
>
>
> Because this is a general overview of all DNS protocols, RFC8484 is by its
> nature a DoH specific treatise.
>

In that case you ought to just point to the text in 8484 or copy it, not
rewrite it.



>>> Section 3.5.1.2
>>>
>>> I admit that I don't understand the purpose of this section.
>>> Concentrating on minutiae, like the details of DHCP or ARP/NDP spoofing, is
>>> far too low level. If we were to simply assume the usual threat model
>>> [RFC3552], then the conclusions here are obvious: if you fail to
>>> authenticate the server, then you get the server that an attacker chooses.
>>>
>>> I would remove this section in favour of improving Section 3.5.1.4,
>>> which addresses the most pertinent question.
>>>
>>>
>>> RFC7626 included Section 2..5.3
>>> https://tools.ietf.org/html/rfc7626#section-2.5.3 ‘Rogue Servers’. This
>>> section is just an update of that text to improve context and remove the
>>> phrase ’rogue server’.  Since the majority of OS implementations still use
>>> these mechanisms today it seems to still be relevant.
>>>
>>
>> Well, as MT says, this is just the 3552 threat model.  The basic fact is
>> that you need a reference to a server that is (1) securely obtained and (2)
>> verifiable against the server itself. Absent that, you are subject to
>> attack by the network.
>>
>>
>> Suggest adding a sentence at the start of the section “[RFC3552] provides
>> guidelines for describing Internet threat models. This section specialises
>> the discussion to the case of DNS resolver configuration.”
>>
>
> Well, that's a start, but the problem is still that it's too low level. If
> you insist on having this section, you should lay out the implications of
> the situation rather than (or at least in advance of) digging into the
> details.
>
>
> The level is detail is entirely comparible to that in the original RFC
> (much of the text is still the same).
>

That doesn't seem like a particularly strong argument. We're revising this
document and the question is what is good now.



As I said to Martin, the section focusses on the impact on the DNS
> resolution path that results from the attack: diversion of traffic and
> traffic capture. Are there other implications you think should be included?
> Please suggest text.
>

I would replace the entirety of this section with:

The Internet Threat model, as described in RFC 3552, assumes that the
attacker controls the network. Such an attacker can completely control any
insecure DNS resolution, both passively monitoring the queries and
responses and substituting their own responses. Even if encrypted DNS such
as DoH or DoT is used, unless the client has been configured in a secure
way with the server identity, an active attacker can impersonate the
server. This implies that opportunistic modes of DoH/DoT as well as modes
where the client learns of the DoH/DoT server via in-network mechanisms
such as DHCP are vulnerable to attack. In addition, if the client is
compromised, the attacker can replace the DNS configuration with one of its
own choosing.

-Ekr




> Sara.
>
>