On 30 Oct 2017, at 8:08, Daniel Kahn Gillmor wrote:
On Mon 2017-10-30 13:11:41 +0000, Sara Dickinson wrote:
if it ends up just being a MAY (although I would like to see SHOULD
as
a minimum for opportunistic).
SHOULD validate, but with what failure mode?
+1 to the question: we're talking about Opportunistic mode here.
are we really saying that
opportunistic SHOULD deliver a DoS instead of a loss of privacy?
Some of us are most emphatically not saying that.
. . .
sure, but this is the case for non-private DNS as well, right? So the
mitigation in this case is with respect to the features that "private
DNS" is supposed to offer. Whatever those features are, they are
absent
given an attacker-controlled DNS resolver. So if the DNS-over-TLS
server is intended to also provide integrity protection, yes, that
would
also be lost. I think we're agreeing here, right? I apologize if
"loss
of privacy" is a misleading shorthand.
Take the case where the DNS server from DHCP really is legitimate.
The
fact that the meta-query answer _could_ be spoofed provides a vector
for an opportunistic client to be directed to an attackers' DNS
server. Note that this attack is not possible on a ’normal’
client
that directly uses the DHCP provided server, the attacker has to
attack each individual query. My concern here is that without DNSSEC
validation of the re-direct Opportunistic clients have an additional
risk of this kind of attack than ’normal’ ones.
ok, i think i understand. The concern is that a
non-network-controlling
attacker who can spoof DNS responses but can't spoof DHCP responses
can
now take over full DNS resolution of opportunistic clients just by
racing (and winning) the legitimate metaquery response.
This is true, but the threat model we're worrying now include all of
the
following characteristics:
* attacker does not control the client's network (otherwise, they
could
redirect the port 853 queries anyway)
* attacker cannot (or has failed to) race the client's DHCP
connection
(otherwise, they'd point to a different DNS server anyway)
* attacker *can* race the legitimate response to the client's
opportunistic metaquery.
* client is in opportunistic mode.
So the question is, in this particular corner case, what is the right
mitigation to the scenario where "if DNSSEC validation of the
opportunistic metaquery fails…" ?
if the answer is "…proceed as though it had not failed (trying to
connect to the preferred server's proposed address), but continue
listening for another response to the metaquery; prefer subsequent
metaquery responses that do have DNSSEC validation over those
responses
that are not DNSSEC validated." Then i'd be ok with it, but it's not
specified in the draft.
If the answer is "…hard-fail and deny DNS service", then i think
that's
incorrect given the goals of opportunistic mode.
Agree. And fully agree that an attacker who can do the third bullet *but
not the second* is a very obscure corner case.
Having this document say, in essence, "you don't get opportunistic
encryption unless you add a DNSSEC validation stack" feels like a
regression to the original goals of this WG.
--Paul Hoffman
_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
