On 8/19/21 7:57 PM, Brian Dickson wrote:
On Thu, Aug 19, 2021 at 10:40 AM Peter Thomassen <pe...@desec.io <mailto: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.
Right, that is obviously the right way to avoid the race condition. I had not thought of the fact that one can provision multiple DS glue records for the same algorithm (but yes, it's just as with any other algorithm), and I think it should be mentioned in the draft. Some follow-up thoughts: a) If the parent is charged with computing and maintaining DS glue (i.e. the registrant does nothing new), then the parent will have to take care that the double-provisioning and clean-up is happening, while adhering to various waiting times. This requires keeping state on the parental side that previously did not have to be kept. Has this been considered? b) If the parent is *not* charged with computing and maintaining DS glue, then the registrant has to do it. Registrants often are already overburdened with uploading regular DS records, not to mention following a specifically timed DS update producure when all they want is add an A glue record. While this is not a problem for ADoT, I think it can be expected that the vast majority of registrations, even if the delegation and child zone use DNSSEC, will not get secured with DS glue, and not receive any of the benefits of glue authentication. As a consequence, one either has to (a) get the parent involved significantly, or (b) the privacy goal of preventing the qname leaking to bogus authoritative nameserver will not be met, and the mechanism is effectively reduced to an ADoT enabler (no offense intended, using pointed language only to dig deeper and spark good discussion). Do you share this asseessment? (I am not making a statement on the significance of the qname leak privacy issue, but my understanding is that preventing that leak is one of the goals of the protocol -- I may be mistaken.)
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.
I really would like to learn of some instances where things went wrong (and then look into what went wrong). Perhaps someone knows? Best, Peter
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> <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 <mailto:DNSOP@ietf.org> > https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop> > -- Like our community service? 💛 Please consider donating at https://desec.io/ <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 <mailto:DNSOP@ietf.org> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop> _______________________________________________ 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
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
