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

[Stephen Farrell <[e-mail]>]

Hi David,

Thanks for taking the time to review this.

On 15/04/2024 23:44, David Blacka via Datatracker wrote:
> 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.

Ta. The authors do agree that it's not actually ready though
so no need to be so nice:-)

> 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? 

Yeah, that's TBD for now. Authors need to chat about it and
probably reflect on how we've seen new tags for SVCB being
added over the last while.

> 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?

Good questions that'll need answering. Will create GH issues
for those (and for issues raised in Martin Thomson's review);
I plan to create those this week when I get time.

> 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?  

It's not common in the web world, but is part of the design
of ECH and defined in that draft. I added a sentence saying
that to my local copy.

> 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.

We already changed some terminology based on Martin's review
so those all now say "backend" rather than "BE."

> 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.

Yeah, there're a few things still to be figured out wrt split
mode but we'll be working on it next week or so - probably ok
to keep an open issue for that.

> 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"?

ZF still seems better to me, but we'll doubtless get feedback
as the draft progresses in the WG and gets further dnsdir
review as things settle down.

> 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.

WFM. Made that change locally.

> 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".

Ta. Fixed locally.

> There are likely others.

Doubtless:-)

Thanks again,
S.

PS: In case someone cares - the draft may well expire before we
get -05 out, but it should be a short interregnum:-)


> 
> 
>