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

[Paul Wouters <[e-mail]>]

You move the Answer section data to the Authoritative section, and add an extended error code that the answer was filtered by policy. This allows a dnssec validator to validate and censor if it is configured to do so.

This is my proposal for rpz-bis which is only waiting on the rpz draft to go through the ISE.

Paul

Sent from mobile device

> On Aug 22, 2019, at 03:00, Eric Rescorla <[e-mail]> wrote:
> 
> 
> 
>> On Wed, Aug 21, 2019 at 10:43 PM Jim Reid <[e-mail]> wrote:
>> 
>> 
>> > On 21 Aug 2019, at 22:13, Stephen Farrell <[e-mail]> wrote:
>> > 
>> > IMO you're both right but not quite using super-precise terminology:-)
>> > 
>> > ...
>> > 
>> > So yep, both give data integrity, just differently.
>> 
>> If we’re being super-precise, that’s not quite right either Stephen. :-)
>> 
>> DNSSEC and DoH/DoT are not different paths to the same end goal of data integrity. They provide different flavours of data integrity.
> 
> This I agree with.
> 
>  
>> DNSSEC validation means you get the truth, the whole truth and nothing but the truth regardless of your choice of resolver or the transport path between you and that resolver. DoH and DoT offer no protection at all from a lying resolver - you’re just guaranteed to receive precisely whatever lies or truth that resolver sends. So in effect you somehow decide to “trust” a TRR and hope for the best. In some cases, that may well be good enough. In others, perhaps not.
> 
> I'd like to push on this slightly, if I may.
> 
> I certainly agree that from a cryptographic perspective, DNSSEC allows you to evaluate whether or not the records that you receive are those which were provisioned (modulo typos, key expiry, etc.). However, as has been observed here a number of times, there are many cases where the resolver desires to elide certain records (e.g., for malware filtering) or to redirect you to some other location (e.g., captive portals). So from a systems perspective it seems like things are more complicated. Suppose that I receive a bogus response to my A record query, how am I to usefully distinguish "this is malware blocking" from "this resolver is malicious"?
> 
> -Ekr
> 
>> 
>> 
>> -- 
>> Add mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/add
> -- 
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add