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

On Thu, Dec 10, 2020 at 4:52 PM Joe Abley <jabley@hopcount.ca> wrote:

> On 10 Dec 2020, at 19:41, Paul Hoffman <paul.hoffman@icann.org> 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.
>
> 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 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.
>
> 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.
>
> Did I read that back correctly?
>
>
Yes.

Brian

> 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.
>
>
> Joe
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>