Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

[Daniel Kahn Gillmor <[e-mail]>]

On Mon 2017-10-30 13:11:41 +0000, Sara Dickinson wrote:
> I really do think a description there of the trade-offs of DNSSEC
> validation are warranted

I agree that a discussion of the tradeoffs involved in DNSSEC validation
of the opportunistic meta-query is warranted.  I just come to a
different conclusion than the requirements in draft-11.

> 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?  are we really saying that
opportunistic SHOULD deliver a DoS instead of a loss of privacy?  I
discuss a few optional responses for failures in opportunistic mode
below.

> I can also recognise the implementation overhead, however this is
> required for only one of the 3 cases of how the client may be
> provisioned:
>
> * IP address only (no meta-query required)
>
> * IP address and ADN (no meta-query required)
>
> * ADN only (meta-query required)
>
> So it is for the case where a client was directly and securely
> configured with just the ADN of a server it expects to provide
> privacy. If a client doesn’t want to implement DNSSEC then it can
> always restrict the opportunistic profile to requiring one of the
> first 2 configurations.

The cheapest and simplest implementation in terms of user experience to
get to verifiable opportunistic profile (that is, a profile that can at
least report that DNS privacy has been achieved, even if it won't be
enforced) seems to be:

  * allow the local administrator to provide a name for the preferred
    DNS resolver

Since it's opportunistic, it can even be enabled by default.

But this is the "ADN only" use case.  Saying it's not usable with the
opportunistic profile without DNSSEC validation would be a shame.

>> Choice 0 is the same outcome as the non-DNSSEC-validating scenario for
>> strict clients (no mitigation),
>
> Agreed - DNSSEC validation just provides earlier detection for Strict clients

or, converts success to failure in the case of DNSSEC misconfiguration
(because the connection would otherwise have succeeded) :(

> I’d disagree that connecting to a server for which the meta-query
> response failed DNSSEC validation results in _just_ a loss of privacy
> for Opportunistic in this case. If the answer was BOGUS then it seems
> reasonable to assume the server is not legitimate and so connecting
> also results in the clients' entire DNS service being controlled by
> the attacker.

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.

If the answer is "…stop trying to use opportunistic DNS privacy
entirely, but fall back to using the DHCP-provided resolver for all
queries" then i think that's a mistake -- we've already demonstrated
that we're in a scenario where the attacker can race the DHCP-provided
resolver and win.  So what do we gain by making this the failure mode?

> Also this is only a guaranteed DoS for the case where there is only a
> single server configured. If there are multiple servers then the
> attacker must spoof the meta-query answers for _all_ the servers to
> achieve DoS. If it only spoofs one then the client can still get
> service.

I think this equivalent to my responses-to-failed-validation #2 --
retrying the opportunistic metaquery.  (also, equivalent to "…but
continue listening…" in the paragraphs above.) I agree that's an
interesting case, but i think it's an additional complexity as yet
unspecified in the draft.  :(

> So one way to look at the trade-off seems to be is it worse that an
> attacker can block your DNS service or gets an extra chance to control
> all your DNS answers? I think you are arguing that for opportunistic
> the latter is preferable because a principle of Opportunistic is that
> it shouldn’t fail? If the WG decided that to be the case then it needs
> to be clear in the document this choice comes with an additional risk
> (and yet still not guarantee of privacy).

it is "an extra chance only" in the scenario where points outlined above
hold.  An attacker who can also race and beat the DHCP server has the
exact same chance already, right?

> Technically his DISCUSS was on a different topic (SPKI handling) as
> Stephane pointed out, this was an issue that came out of a separate
> comment he made.

Hm, sorry, i'll try to follow up on that in the other sub-thread.

Thanks for the discussion.

    --dkg