On Thu, Dec 10, 2020 at 4:52 PM Joe Abley <jab...@hopcount.ca> wrote:
> 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? > > 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
