On Sat, 9 Dec 2023 at 05:54, Watson Ladd <watsonbladd@xxxxxxxxx> wrote:
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.
We added a new section to address this comment, please see https://www.ietf.org/archive/id/draft-ietf-add-split-horizon-authority-07.html#section-10
-Tiru
>
> --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
