Re: [Add] data integrity and DNSSEC or DoH/DoT

[Brian Dickson <[e-mail]>]

> On Aug 21, 2019, at 6:27 PM, Stephen Farrell <[e-mail]> wrote:
> 
> 
> Hiya,
> 
>> On 21/08/2019 23:14, David Conrad wrote:
>> Stephen,
>> 
>> On Aug 21, 2019, at 2:47 PM, Stephen Farrell
>> <[e-mail]> wrote:
>>>> DNSSEC and DoH/DoT are not different paths to the same end goal
>>>> of data integrity. They provide different flavours of data
>>>> integrity.
>>> 
>>> I don't agree that the goals are precisely the same as the actors
>>> involved in providing the security services differ. There's a lot
>>> in common, but they aren't identical.
>> 
>> You appear to be agreeing with Jim.
> 
> I often do :-)
> 
>> DNSSEC provides data integrity _for what the zone authority put into
>> the zone_, regardless of how it gets to the client.
>> 
>> A TLS channel between a client and a resolver (DoH or DoT) provides
>> data integrity and confidentiality (and _resolver_ origin
>> authentication)  _for what the RESOLVER chooses to serve_.
> 
> Yep.
> 
>> DoH _will not help_ if the “trusted” resolver is compromised to
>> modify the response (something I suspect concentrating the resolver
>> function will encourage).  DNSSEC would help that particular attack.
> 
> Yep.
> 
> Those are both true statements. There are equally true
> statements that'd demonstrate cases where DoH or DoT do
> better than DNSSEC - IIUC an important one being: given
> the (unfortunate) relative sparsity of DNSSEC signed
> data, the data integrity service that DoH or DoT can
> provide could well be argued to be as good as what a
> client can get via DNSSEC when the full set of queries
> a client makes are taken into account.

Actually, no, it cannot, at least if the only trust anchor on the DNSSEC validation is the ICANN/IANA root trust anchor.

The protection of data integrity is almost entirely a dependency on whether the resolver validates DNSSEC or not.

If the resolver does not validate, then the resolver is in an unknown data integrity situation for DNSSEC signed zones. Use of DoT/DoH to such a resolver does not change anything. It is strictly garbage in, garbage out (or clean data in, clean data out if no data tampering was attempted). DoX neither elevates nor lowers the integrity of the data compared to the original zone data. NB: If the incoming DNS data was altered, the adversary succeeds EVEN IF THE DATA WAS DNSSEC SIGNED.

Comparing against anything other than the original zone data is meaningless (with the exception of filtering services, which is relevant only if the client opted in to using a resolver that does such.)

A non-DNSSEC zone is basically fair game, irrespective of any validation or channel security. In addition to on path attackers, unsigned zones can be attacked at the resolver by off-path adversaries. They are also susceptible to local attacks on the resolver server itself, and to malicious activity by insiders. 

A DNSSEC signed zone validated by the DNS end client is immune to all of these attacks, reducing otherwise successful attacks to DOS.

If the resolver does validate, DoT/DoH adds nothing at all to the data integrity state.

Here is where it is fair to compare DoX to DNSSEC: From a validating resolver to a client.

The data integrity starts in a known state on the validating resolver.

DoX prevents changing the data integrity via channel security.

DNSSEC “prevents” changing the data integrity via cryptographic signatures which prevent tampering by detection of tampering.

(Both DoX and DNSSEC are susceptible to DOS by an on-path adversary.)

In summary:
If the resolver validates DNSSEC signed data, DoX and client DNSSEC validation have exactly the same protection against tampering.
If the resolver does not validate DNSSEC signed data, a DNSSEC validating client can still detect tampering and protect itself, whereas DoX does not and cannot.

If the data is not DNSSEC signed, the only path component protection occurs between the resolver and client.

A risk analysis of DNS vs tampering would show the place to attack DNS is not on the client side, but rather on the authority side. The reason is that a single successful attack impacts ALL clients rather than a single clients. This also means the more clients a resolver has, the more valuable it is to an attacker.

As to the perceived value of DNSSEC based on how many domains are signed, there is more to this than numbers or percentages.

The flaw is in treating all domains as equally valuable, rather than weighting those values.
You can get to a very high percentage of aggregate value with a small number of zones, if the small number are particularly important, like all of the Fortune 500 or all national governments or a significant portion of critical infrastructure or a combination of those.

And in particular, the value to the individual domain owner doing DNSSEC is ignored in use of raw numbers alone. The value of DNSSEC to joes-bait-shop.hosted-dns.example.com is likely a lot less than iana.org or whitehouse.gov (I’m guessing).

A large bank or government department, for examples, is probably already using DNSSEC. Clients who neither use a validating resolver nor do client-side validation are failing to protect themselves.

Even if the raw numbers are not so great today, if they improve drastically (eg up to 40% of all of DNS zones) in 2020, IMHO it behooves us to not reject those protections, which the domain owners themselves have selected; architectural and operational decisions should be being made in a manner compatible with DNSSEC validation.

Remember, the signing in DNSSEC is not done by the resolver operators, it is done by domain owners themselves (or parties to whom they have outsourced this).

Brian