On Thu, Aug 19, 2021 at 10:40 AM Peter Thomassen <pe...@desec.io> wrote:
> Hi Brian, > > The proposal aims to authenticate parental NS and glue records by having > the parent sign their hash digests, embedded in new types of DS records. > > 1.) The separation of the data which requires authentication (parental NS > + glue records) from the place where authentication is provided can lead to > a race condition: What happens if updates do the NS or glue records have > been seen and cached by a resolver, but an old DS RRset is cached (or vice > versa), so that digests mismatch? How does this interfere with the notion > that it is acceptable to cache an RRset until its TTL expires? > The process for changing glue or NS records is something that typically is already dealt with by domain owners, by a sequence of changes and waiting periods based on TTL. (That generally involves changes to apex NS and delegation NS sets in a specific order and involving waiting intervals based on TTL, as well as having both sets of NS serving data during the change of NS.) This would not be that different. The general practice would be "make before break". Add DS records to the set, wait, make the changes, wait, remove old DS records that are no longer required. This prevents the mismatches from happening, and is compatible with cache assumptions regarding TTL. > 2.) Conceptually, the goal of authenticating parental NS and glue records > can also be achieved by signing them directly at the parent. In this case, > the signature is bound directly to the data, and no race condition occurs. > One may object that the parent is not authoritative, but that's merely a > legalistic point: If we change the law and declare that the parent *can* > sign these records, then authentication of parental NS and glue records > would in fact be achieved. Thus my question -- why not pursue this route? > A number of reasons, including the answer to #3 below. There is also the problem of backward compatibility during any deployment. Whatever responses are returned by a TLD authority server for delegations, would need to work with both existing resolvers and with updated resolvers. Basically, my proposal is guaranteed to not break existing resolvers, and to allow resolvers to use added records to add the functionality. The other options are basically to use new RRTYPE(s), plus getting all the TLDs to implement those unilateral changes on the parent side or to do #3 (see below for why not). That is a long term solution, and the correct way to eventually deprecate any hack. So, the reason for my proposal is not to avoid doing new RRTYPEs, it is to get something workable deployed on a faster timeline than decade(s). The motivation is that there are missing parts needed for ADoT, specifically validating NS delegations (NS names), needed for the certificate name for TLS. > > 3.) Have any experiments been done to determine whether adding RRSIGs to > parental NS and glue records breaks existing deployments? (Pointers > welcome.) > > I don't have pointers offhand, but yes, this has been experimented with, is my understanding. (Anyone have pointers? It might be nice to have them handy.) The results and behavior may have varied, but were definitely not universal success. I'm not sure if some implementation combinations might have "worked", but certainly not the majority of combinations. Brian On 8/12/21 3:15 AM, Brian Dickson wrote: > This is the work I will be submitting in DNSOP. > > This is what has been described as a “hack”, but provides a needed validation link for authoritative servers where the latter are in signed zones, but where the served zones may not be signed. > > NB: It overlaps with the recent DPRIVE draft that Ben S submitted recently. > > It will likely be the case that those overlaps need to be reconciled, based on use cases and scope. > > I think there are valuable use cases other than privacy, which would make this more appropriate for DNSOP. > > Comments are welcome. > > The draft can be found at: > > > https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-00.txt < https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-00.txt> > > Brian > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 _______________________________________________ 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
