Re: [Add] Secdir last call review of draft-ietf-add-split-horizon-authority-06

[tirumal reddy <[e-mail]>]

On Sat, 9 Dec 2023 at 06:02, Watson Ladd <[e-mail]> wrote:

> On Mon, Nov 27, 2023 at 10:23 PM tirumal reddy <[e-mail]> wrote:
> >
> > On Fri, 24 Nov 2023 at 20:51, Watson Ladd via Datatracker <
> [e-mail]> wrote:
> >>
> >> 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.
> >
> >
> > Sure, we will fix the text as follows:
> > If this resolver acts as an authoritative server for some names and
> provides different answers for those domains depending on the source of the
> query, we say that the network has "split-horizon DNS", because those names
> resolve in this way only from inside the network.
>
> Sounds good.
>
> >
> >>
> >>
> >> 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.
> >
> >
> > It is discussed in the third paragraph of Section 5. For instance, in
> the case of DNR, the DNS client would anyway do PKIX validation and
> validation technique in RFC 6125 (see
> https://www.rfc-editor.org/rfc/rfc9463.html#section-3.3). The DNS client
> would have to check if the name of the local encrypted resolver matches the
> ADN in any one of the authorization claims.
>
> I was about to say that now that I've looked again at it I'm
> deconfused, but on thinking some more I'm confused again.
>
> How about switching to the following to make it clear? "If the local
> resolver is identifed by name, the name used to find it must equal the
> ADN in an authorization name used to convey authority for the domain
> being looked up. Otherwise the ADN must be presented on an X509
> certificate shown by the resolver, according to the rules in RFC
> 6125".
>

I propose the following change:

If the local encrypted resolver is identified by name (e.g., DNR), that
identifying name MUST be the one used in any corresponding Authorization
Claim. Otherwise (e.g., DDR using IP addresses), the resolver MUST present
a PKIX certificate containing a subjectAltName that matches the
Authorization Claim using the validation techniques for matching as
described in [RFC6125].

-Tiru


>
> Sincerely,
> Watson
>
> --
> Astra mortemque praestare gradatim
>