Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))

[Paul Hoffman <[e-mail]>]

On Dec 10, 2020, at 4:52 PM, Joe Abley <[e-mail]> wrote:
> 
> On 10 Dec 2020, at 19:41, Paul Hoffman <[e-mail]> wrote:
> 
>>> "Authenticate authoritative servers" is a bit vague for me. Parent and child are namespace concepts and not relying parties that you'd ordinarily expect to be able to authenticate anything.
>> 
>> A resolver asks a parent what the NS records are for the child. Today, an on-path attacker can change the answer and the resolver would not be the wiser, so the resolvers cannot trust such answers to do things like look up TLSA records. There is a desire for resolvers to be sure that what the child NS records they receive from the parent is what the parent has in its zone for the child so they can use this information to ask for TLSA records.

> Did I read that back correctly?

Somewhat, but not completely.

> The problems that DNSSEC is trying to solve are with identifying inauthentic data ultimately requested by applications. If an intermediate referral response includes an inauthentic NS RRSet with no RRSIGs

or an NS RRset with bogus RRSIGs

> it cannot be identified as inauthentic, but it doesn't really matter because any data that is expected to be signed from the inauthentic servers will fail validation and the application will be protected.
> 
> The problems that dprive is trying to solve concern surveillance opportunities and information leakage. that if an imtermediate referral response includes an inauthentic NS RRSet with no RRSIGs it could cause queries on behalf of an application to be harvested by an untrusted third party at one of those inauthentic servers, which could represent a surveillance opportunity.

That is true so far, but some folks have informally gotten excited about authenticating intermediate referral responses for other reasons. (They can speak for themselves; that's not my use case yet.)

> The proposal is hence to provide a way for an intermediate referral response that includes an inauthentic NS RRSet to be identified as inauthentic so that subsequent queries to the untrusted third party servers can be suppressed.

Again, this is true so far, but others have hinted that they might use the authentication for more.

> I've now typed "inauthentic" enough that I am starting to doubt that it is a word, but "bogus" has a particular and different meaning in DNSSEC so I was trying to avoid it.

You even skipped using "bogus" once above. :-)

--Paul Hoffman