Re: [Last-Call] Dnsdir last call review of draft-ietf-drip-auth-43

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Di, thanks for your review of the I-D.

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.

--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC

From: Di Ma via Datatracker <noreply@xxxxxxxx>
Sent: Monday, January 8, 2024 11:34 AM
To: dnsdir@xxxxxxxx <dnsdir@xxxxxxxx>
Cc: draft-ietf-drip-auth.all@xxxxxxxx <draft-ietf-drip-auth.all@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx>; tm-rid@xxxxxxxx <tm-rid@xxxxxxxx>
Subject: Dnsdir last call review of draft-ietf-drip-auth-43
 
Reviewer: Di Ma
Review result: Almost Ready

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.


-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux