On 10 Dec 2020, at 19:41, Paul Hoffman <paul.hoff...@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? 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
