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

[Sara Dickinson <[e-mail]>]

> On 30 Oct 2017, at 15:08, Daniel Kahn Gillmor <[e-mail]> wrote:
> 
> 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.

Can we separate out Opportunistic Privacy from Opportunistic DNSSEC (which I don’t think is really a thing, apart from a logging mechanism)? They are orthogonal.

Because if not…. are you saying that a fully validating stub using Opportunistic privacy mode shouldn’t DNSSEC validation anything, ever? Or it can validate all answers except the one for it’s DNS resolver? :-)

> 
>>> 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) :(

Ok, but … If the DNSSEC is misconfigured for a privacy server then DANE authentication won’t work either…

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

I don’t buy the ‘if DHCP is already vulnerable we shouldn’t worry about securing the meta-query’ argument. I'd like to think we are designing Opportunistic such that the meta-query is at least as secure as whatever mechanism is or might be used in future to obtain the default DNS server so that opportunistic is no weaker than ’no privacy’.

I hear the case that requiring DNSSEC validation could block deployment for the specific case of ADN only + Opportunistic. So ti sounds like it boils down to two alternatives in section 7.2:

“ Such records SHOULD be validated when using Opportunistic Privacy.”

“ Such records MAY be validated when using Opportunistic Privacy.”

I’d obviously favour SHOULD.

Sara