Re: Dnsdir last call review of draft-ietf-httpbis-alias-proxy-status-05

Hi Jim,

Thanks for the review! Much appreciated.

Some responses are inline.

> On Oct 16, 2023, at 10:21 AM, Jim Reid via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Jim Reid
> Review result: Ready with Nits
> 
> I am the dnsdir stuckee to review this I-D.
> 
> The document is clear, concise and well written. If only all RFCs and I-Ds had
> those properties...
> 
> I particularly like the attention in Section 2.1 to the encoding of special
> characters. Consideration of using the dot character in a label greatly appeals
> to my poorly hidden DNS Bad Idea Fairy. Congratulations!
> 
> I think there are some nits:
> 
> 1) A sentence could be added to say that CNAME chaining -- ie A's a CNAME
> pointing at B which is a CNAME pointing at....Z  -- should be avoided because
> it's a Bad Idea. It needlessly complicates resolving: more lookups, loop
> detection, etc. The outcome is implementation dependent too because not all
> resolvers handle CNAME chains in the same way. Implementations can set
> arbitrary limits on the length(s) of the CNAME chain(s) they follow.

A fair point! Is there a document that can be referenced? I don’t think this document at hand is the one that needs to come out and make this statement (mainly because we’re just reporting the chains we see, of which there are many, rather than trying to make them), but I totally agree and would be happy to add a pointer to the best place that gives that advice.

> 
> 2) If DNS info can't be validated, it seems bad/stupid/dangerous/wrong to use
> that to make security decisions. IMO the SHOULD NOT in Security Considerations
> would be better as a MUST NOT. Though I don't feel strongly enough about this.

That’s also a fair point! I’m tempted to see how the IESG reviews take this particular point. I can see an argument either way, and could imagine some very edge-case like reasons to include this in a security decision. For example, if you expect to always see some expected/good values in this response, and you get something different, you could choose not to use the proxy or do some “fail closed” behavior. Nothing should be done to trust an endpoint more based on the value, but potentially actions can be taken to trust it less.

> 
> 3) It might be worth mentioning that a proxy could lie when it adds a
> next-hop-aliases parameter: ie claiming the next or previous hops are not the
> actual ones that were used. I don't know or care enough about web stuff to tell
> if that matters or not.

I think this is partly implied by:

"In general, clients can trust information included (or not included) in the next-hop-aliases parameter to the degree that the proxy and any resolvers used by the proxy are trusted.”

So — if we trust the proxy, then great! Otherwise, it totally can lie.

> 
> 4) There's a tiny, tiny chance that DNAME RRs could get used instead of CNAMEs.
> I doubt these would ever feature in the proxies or the DNS names envisaged in
> the I-D. However from a theoretical (or DNS purist's) perspective, the I-D
> should explain this, if only for completeness.

I believe in this case that since the recursive resolvers should be doing CNAME synthesis from DNAMES (https://www.rfc-editor.org/rfc/rfc6672#section-3.4) that the proxy, as a client, would only see CNAMES. Let me know if I’m missing something there.

Best,
Tommy

> 
> 
>