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 07:19:36 -0400, Paul Wouters wrote:
> Just to be clear. DNSSEC provides authentication of data. TLS provides
> privacy of data. Both are needed so I am against this proposed change
> to remove DNSSEC validation as a requirement. DNSSEC is part of the
> core DNS. It's not a cherry.

I'm not claiming that no clients should implement DNSSEC validation.  I
would be happy if every client did so.  Please don't mistake this as a
generic judgement on DNSSEC.  It's about one particular situation where
hard-fail is a bad idea.

In particular, the situation under discussion is what clients should do
in the event of a DNSSEC validation failure of an opportunistic
"meta-query".  As a reminder, the "opportunistic meta-query" is the
best-effort lookup of the IP address(es) of the preferred DNS privacy
resolver, under either Strict or Opportunistic profiles.

In either profile, the meta-query itself is opportunistic -- it's an
attempt to find some channel to the preferred resolver.  But let's look
at the two profiles separately:

 a) under the opportunistic profile, dropping the response to an
    opportunistic meta-query in the event of a DNSSEC validation failure
    transforms a loss of privacy into a DoS.  This does not meet the
    stated goal of the opportunistic profile, "maximum chance of DNS
    service".

 b) under the strict profile, dropping the response to an opportunistic
    meta-query in the event of a DNSSEC validation failure will result
    in the same outcome (DoS) where the response to the meta-query comes
    from an attacker, because the attacker couldn't have provided a
    valid TLS endpoint in the first place.  But in the scenario where
    DNSSEC either isn't available, or is misconfigured, it converts a
    successful connection attempt into a DoS.  This is a net loss for
    the user.

Put more simply:

    Opportunistic meta-queries are opportunistic.

Encouraging or requiring hard-fail to DNSSEC validation of an
opportunistic meta-query just amounts to a reduction of service, and
provides no security or privacy improvements that i can see.

If the goal is to enforce corroborative authentication of the DNS
privacy server (e.g. via both DNSSEC and the X.509 cartel), i welcome a
writeup of a "Extra Strict" profile that adds a DNSSEC validation
requirement to the Strict profile.  But that's not this draft.

         --dkg