Re: [dns-privacy] Threat Model

["Livingood, Jason" <[e-mail]>]

In the -01 I added a parenthetical to address this suggestion and later WG discussion. Not sure if we’re there yet so open to specific wording suggestions.
//from GH repo//
# Threat Model and Problem Statement

Currently, potentially privacy-protective protocols such as DoT provide encryption between the user's stub resolver and a recursive resolver. This provides (1) protection from observation of end user DNS queries and responses as well as (2) protection from on-the-wire modification DNS queries or responses (including potentially forcing a downgrade to an unencrypted communication). Of course, observation and modification are still possible when performed by the recursive resolver, which decrypts queries, serves a response from cache or performs recursion to obtain a response (or synthesizes a response), and then encrypts the response and sends it back to the user's stub resolver.

But observation and modification threats still exist when a recursive resolver must perform DNS recursion, from the root to TLD to authoritative servers. This document specifies requirements for filling those gaps.

From: dns-privacy <[e-mail]> on behalf of Eric Rescorla <[e-mail]>
Date: Friday, November 1, 2019 at 2:11 PM
To: "[e-mail]" <[e-mail]>
Subject: [dns-privacy] Threat Model

It seemed like it might be a good idea to take a step back and talk
about threat model to see if we're all on the same page.

The set of threats I am concerned with is primarily about an on-path
active attacker who learns the query stream (i.e., the domains being
queried) coming out of the recursive resolver. It's of course mostly
inevitable that the attacker learns which authoritative servers are
being queried, but I think we can all agree there's still plenty of
information to leak here [0].


In the current DNS, such an attacker can of course just perform a
passive attack by listening to the DNS query traffic. It's possible to
straightforwardly exclude this attack by opportunistically attempting
DoT [1] to the authoritative. However, an active attacker can mount a
downgrade attack on the negotiation, forcing you back to
cleartext. So, unless you have a secure way of:

(1) knowing the expected name of the authoritative for a given query
    and that it supports DoT
(2) verifying that the server you are connecting to actually has
    that name

Then the attacker can just mount a MITM attack on your connections and
collect this data by proxying the traffic to the true authoritative.

Do people agree with this assessment of the situation? Is this form
of attack something they agree should be in scope?

-Ekr

[0] There are of course also integrity issues here, but (1) those
are addressed by DNSSEC and (2) if you solved the active attack
problem, that would provide some measure of integrity for the data.

[1] Or any secure transport such as DoH, DoQ, tcpcrypt, etc.
but given the focus of this group, I'll just say DoT.