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 6:11, Sara Dickinson wrote:

> 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.

There are many ways to get a BOGUS response that have nothing to do with 
the information being "not legitimate". Typically today, BOGUS comes 
from misconfigured servers such as expired keys, some nameservers out of 
sync, and so on.

You cannot infer from a BOGUS response about why it is bogus.

> 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.

Spoofing in normal DHCP and spoofing without DNSSEC seem equivalent to 
me.

> 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.

...unless the attacker can spoof the (typically) two servers that the 
client has addresses to.

> 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 only an "additional risk" for a very limited attacker who can only 
attack one of a set of addresses.

If the WG wants to go down the path of making Opportunistic encryption 
even more difficult in order to feel that we offered the best security, 
requiring DNSSEC on the client is a good way to do that. I would still 
prefer more ubiquitous encryption.

--Paul Hoffman