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 <dns-privacy-boun...@ietf.org> on behalf of Eric Rescorla
<e...@rtfm.com>
Date: Friday, November 1, 2019 at 2:11 PM
To: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
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.
_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
