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

["Paul Hoffman" <[e-mail]>]

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