On Mon, Nov 27, 2023 at 7:41 PM Ben Schwartz <bemasc@xxxxxxxx> wrote: > > Regarding rotation: when the authorization claim changes, the parent must publish two Verification Records, containing the old and new token values. Apologies for the late response: I didn't gather that you can have multiple verification records, maybe explicitly note this in Section 5? Or maybe it's obvious to those steeped in DNS enough. > > --Ben Schwartz > ________________________________ > From: Add <add-bounces@xxxxxxxx> on behalf of Watson Ladd via Datatracker <noreply@xxxxxxxx> > Sent: Friday, November 24, 2023 10:21 AM > To: secdir@xxxxxxxx <secdir@xxxxxxxx> > Cc: add@xxxxxxxx <add@xxxxxxxx>; draft-ietf-add-split-horizon-authority.all@xxxxxxxx <draft-ietf-add-split-horizon-authority.all@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx> > Subject: [Add] Secdir last call review of draft-ietf-add-split-horizon-authority-06 > > !-------------------------------------------------------------------| > This Message Is From an External Sender > > |-------------------------------------------------------------------! > > Reviewer: Watson Ladd > Review result: Has Issues > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These comments > were written primarily for the benefit of the security area directors. Document > editors and WG chairs should treat these comments just like any other last call > comments. > > The summary of the review is has issues. I found a few editorial things, and > have one question, but I suspect that these can be resolved easily. > > Firstly the description of split horizon seems to say that any time the > resolver is authoritative for just some names and recurses for others. I don't > think this is right: the split is that the answers given are different from > what they are for any other resolver, and that's what creates the need for this > draft. This is defined correctly in section 2, it's just a need to reword the > intro slightly. > > In Section 5 I think more clarity is needed about which DNS name needs to > match, and how the matching is to be done, perhaps citing a UTA doc. I think > what's supposed to be said is that the ADN is a subjectAltName matching under > RFC 6125. > > The one more serious question I have is how does rotation work. The DNS changes > may not take place together with the authorization claim transmission, and this > seems underspecified. Does the split horizon break until the two are in sync > again? > > Sincerely, > Watson Ladd > > > -- > Add mailing list > Add@xxxxxxxx > https://www.ietf.org/mailman/listinfo/add -- Astra mortemque praestare gradatim -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
