On 19. 03. 26 5:59, tirumal reddy wrote:
addresses comments received during WGLC,
particularly those raised by Petr Špaček.
First, I apologize for the mangled review text! Apparently Datatracker
ate some of the newlines and it made it really hard to read even for me,
which I unfortunately noticed only today.
I went through -18 and my -17 review and I think this mess contributed
to skipping over several points I raised. The first one is crucial as
the format under-specification was not addressed:
-18 says:
4. I-JSON in EXTRA-TEXT Field
... data in the EXTRA-TEXT field [RFC8914] encoded using the Internet JSON
(I-JSON) message format [RFC7493].
It is still missing a specification the data must be a JSON Object
(emphasis on the capital O). I-JSON message could be an array, even
null/false/true. I suggest replacing the sentence above with something like:
"... data in the EXTRA-TEXT field [RFC8914] as JSON Object encoded using
the Internet JSON (I-JSON) message format [RFC 8259 section 4]."
5.2. Server Generating Response
If the SDE option was not present in the DNS request, the DNS server MUST NOT include structured JSON data.
What if an implementation does not produce humand-readable version? Does
that mean it MUST NOT give back any information at all? Returning
unsolicited SDE does not result in any interoperability problem, it just
might be less convenient for a person to read it. But having something
is certainly better than not returning anything at all.
I suggest change to something like this:
"If the SDE option was not present in the DNS request, the DNS server
SHOULD include human-readable EXTRA-TEXT accordance with [RFC8914]."
5.3. Client Processing Response
8. If the DNS client has enabled the opportunistic privacy profile for DoT (Section 5 of [RFC8310]) and the identity of the DNS server cannot be verified, ...
This paragraph has leftover over-specification for DoT which was
corrected in other places. Simply shortening it would address this
issue. E.g."If the identity of the DNS server cannot be verified, ..."
If you really want to single out DoT, then perhaps something like:
"If the identity of the DNS server cannot be verified (e.g. with
opportunistic privacy like Section 5 of [RFC8310]), ..."
> 5.3. Client Processing Response
In opportunistic discovery [RFC9462], where only the IP address of the DNS
server is validated and the server identity is not authenticated, the DNS
client MUST ignore ...
Same here. There might be a different mechanism in use which is similar
but different than RFC 9462.
I suggest:
"If only the IP address of the DNS server is validated and the server
identity is not authenticated (e.g. with opportunistic discovery
[RFC9462]), ..."
> 5.3. Client Processing Response
> 10. If a DNS client has enabled strict privacy profile (Section 5 of
[RFC8310]) for DoT, the DNS client requires an encrypted connection and
successful authentication of the DNS server. In doing so, this mitigates
both passive eavesdropping and client redirection (at the expense of
providing no DNS service if an encrypted, authenticated connection is
not available). If the DNS client has enabled strict privacy profile for
DoT, the DNS client MAY process the EXTRA-TEXT field of the DNS response.
This seems to over-specify things again. E.g. an ordinary Firefox
browser today, doing DoH to a selected DoH resolver, will not fulfill
this specification!
I suggest simplifying it to:
"If the connection to a DNS server is authenticated and integrity
protected, the DNS client MAY process the EXTRA-TEXT field of the DNS
response."
That's technology neutral and focuses on the important properties the
SDE protocol relies on - authentication and integrity protection. (For
the fun of it, TLS with NULL cypher-suite would suffice as it provides
integrity protection without encryption :grin:)
10.1. Authentication and Confidentiality
This specification assumes the use of encrypted DNS transports and recommends authenticated connections to the DNS server.
After the changes above, this would read better as e.g.
"This specification assumes the use of integrity-protected DNS
transports and recommends authenticated connections to the DNS server."
Nit:
I suggest adding "SDE" acronym definition into section 2. Conventions
and Definitions .
Thank you for patience with me.
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
