[TLS] Dnsdir early review of draft-ietf-tls-wkech-04

[David Blacka via Datatracker <[e-mail]>]

Reviewer: David Blacka
Review result: Ready with Issues

This is an early review, so the actual status simply means that I didn't find
anything alarming in this draft.

At its core, this I-D is a registration for a well-known URI, using the
criteria described in RFC 8615.  The use of this well-known URI is that a
separate software component from the web server itself can poll the URI and,
based on the response, update DNS RRsets.  This seems pretty straightforward.

The JSON format is encoding of the SVCB ServiceParams, plus the priority,
target, and "regeninterval" fields.  This makes sense, since we are asking the
"Zone Factory" to generate a SVCB or HTTPS record from the data.  This leads to
some obvious questions:

* What happens if there are unknown keys in the JSON?  (e.g, is the response
considered invalid?  Or does the Zone Factory ignore them and create the RRs
anyway?) * how are changes to the underlying SVCB service parameter registry
handled?  This I-D asks IANA to create another registry for the JSON fields. 
Does this have to "keep up" with the SVCB IANA registry?

This I-D talks about web servers running in "split mode".  Is this a common
term in the web world?  Is there a reference to this practice?  If not, could
it be described more completely? I found the abbreviation "BE" to be jarring,
possibly more so because it is used without any English articles.

Since I don't really understand "split-mode" (which is presumed to be the norm
based on the example), I don't understand why the distinction is relevant to
the proposal?  Does the Zone Factory behave differently if the web server is in
"split-mode"?  Section 5 suggests that is does, but I'm not sure exactly what
is going on there.

I found the term "Zone Factory" a bit odd as well, but I couldn't think of a
better name.  "Zone Agent"?  "SVCB Update Client"?

The I-D in section 6 says:

    ZF SHOULD set a DNS TTL short enough so that any cached DNS resource
    records are likely to have expired before the JSON object's content is
    likely to have changed. The ZF MUST attempt to refresh the JSON object and
    regenerate the zone before this time. This aims to ensure that ECHConfig
    values are not used longer than intended by BE.

This could be couched more precisely in terms of "regeninterval".  We might
want to avoid being overly prescriptive, though.  Something like "The ZF SHOULD
set a DNS TTL less than 'regeninterval'", perhaps.

In Section 6 (and maybe section 3), it isn't spelled out how the Zone Factory
determines the "owner" of the SVCB and or HTTPS records.  I only ask about this
because, if it isn't the domain part of the well-known URI used, then it should
be accounted for in the JSON format.

I'll also note that this early I-D does have a number of obvious typos, at
least one was noticed by the ART reviewer:

* "For many applications, that requires publication of ECHConflgList data
structures in the DNS" -- there is an ell masquerading as an i. * "Zone factory
(ZF): an entity that has write-accsss to the DNS" -- should be "access".

There are likely others.