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 responseconsidered 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 commonterm 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:-)
OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
