Re: [Add] What to do in this potential working group

[Brian Dickson <[e-mail]>]

On Wed, Aug 21, 2019 at 2:17 PM David Conrad <[e-mail]> wrote:

> Alec,
>
> On Aug 21, 2019, at 11:06 AM, Alec Muffett <[e-mail]> wrote:
>
> On Wed, 21 Aug 2019, 18:59 David Conrad, <[e-mail]> wrote:
>
>> The only way to truly ensure a trustworthy answer is to protect the
>> actual answer. Which is what DNSSEC does.
>>
> Fortunately we do not have to wait for DNSSEC in order to get answers from
> the people from whom we wish them supplied, privately and untampered-with,
> which is the whole point of DNS over HTTPS.
>
>
> As mentioned, this is not the traditional answer for what is “trustworthy”
> when it comes to DNS data: instead of trusting the zone owner (more
> specifically, the holder to the zone signing key), you are trusting the
> resolver operator.
>
> The data is ONLY private between the end user and the resolver operator.
> It is NOT private to the resolver operator (something people have been
> repeatedly pointing out) nor is it private between the resolver operator
> and the authorities.
>
> Further, you cannot ensure to the end user that the “trusted” resolver
> operator has not tampered with the data, be it due to court order, internal
> attack, software bugs, etc.
>

It is probably useful to highlight the impact of "local policy", especially
with respect to trust anchors.
For example, it might be the case that a given resolver operator has been
compelled to install (and use) some additional trust anchor(s).

Under that resolver operator's local policy, it is possible that the
validity of a given DNS answer from an authority, only due the use of an
additional trust anchor.

In that circumstance, a validating stub would actually determine that the
DNS answer it received from that resolver is BOGUS.

The resolver operator might not be directly involved in modification of the
DNS answer and signatures. For example, there could be a state actor in the
same jurisdiction as the operator and the respective court. The additional
trust anchor presumably would have been used by the state actor for signing
the substituted data. (This would be analogous to the root CA thing being
used for TLS MITM ongoing somewhere.)

Since a resolver operator's data is mostly cached, and cached based on
DNSSEC validity if they validate, such state actions scale extremely well.
This is a significant reason that DNSSEC was designed from the ground up
for client (stub) validation: trust, but verify.

Note: Having multiple resolver operators to choose from helps this
situation, but ONLY if the stub does local validation, and if the
jurisdictions for those operators was different.  The stub treats the
invalid data as a failure, and uses the other provider. This only occurs if
the failure to validate is detected by the stub, by local validation.

NB: recursive-to-authoritative is not encrypted, and on-path attackers can
modify the data. DNSSEC enables detection of this tampering via validation
on signed data, modulo the trust anchor(s) in use.

Brian


>
> Again, DNS over HTTPS protects the data channel. It does NOT protect the
> data.
>
> Regards,
> -drc
>
>