On 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.
> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
