kc2rxo
commented
10 months ago An official response has been sent to this comment as follows:
It’s not clear if enhanced error codes will serve a useful role in DRIP. It probably won’t matter to an end client what sort of failure occurred. All that matters is the lookup failed. Which could mean a DET has expired or been revoked and some out-of-band (ie non-DNS) mechanism could be needed to confirm that.
New(ish) DNS developments like DOA and DSO are unlikely to figure in DRIP deployments because in general DRIP clients will not have the hardware and networking resources to maintain state or an encrypted transport.
I think this document is almost ready except for some specifications regarding the DNS.
In section 3.1.1., "An Observer SHOULD query DNS for the UA's HI. If not available it may have been revoked. Note that accurate revocation status is a DIME inquiry; DNS non-response is a hint that a DET is expired or revoked. It MAY be retrieved from a local cache, if present. The local cache is typically populated by DNS lookups and/or by received Broadcast Endorsements (Section 3.1.2)."
By comprehending RFC9374 and RFC9434, I think it would bring about new operational considerations to leverage current DNS to meet the need of naming in the context of UAS, especially due to DET the new DNS RR proposed by draft-ietf-drip-registries-14. It is therein inevitable to handle some anomalies of DNS queries triggered by DRIP-based Authentication. The current text here is not adequate for the consistency among different implementations. If the authors consider this issue could be left to private implementation, it should be explicitly stated here. Otherwise，I suggest authors consider adding extra content regarding DNS rcode extension.
On the whole, I think authors should refer to which kind of DNS specification/RFCs normatively used by DRIP since the DNS is key to the DRIP architecture, given that DNS is evolving to DoH and DSO and so on.