I reviewed this document as part of the Security Directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Security Area
Directors.  Document authors, document editors, and WG chairs should
treat these comments just like any other IETF Last Call comments.

Document: draft-ietf-radext-radiusdtls-bis-14
Reviewer: Russ Housley
Review Date: 2026-02-13
IETF LC End Date: Unknown
IESG Telechat date: Unknown

Summary: Has Issues


Major Concerns:

Section 3.2: The document says that implementers "MUST follow
the recommendations given in [RFC9325]".  No worries there.
However, you do not want to revise this document just because
[RFC9325] gets revised.  Instead say "[RFC9325] or its successors"


Minor Concerns:

Section 3.2: The "must" in the second sentence seems to be a consequence
of the "MUST" in the first sentence.  I suggest rewording to avoid
implementers wondering whether this ought to be upper case.  Perhaps
the second sentece could start with: "as a result, all data ...".

Section 3.2: I agree that 0-RTT is inappropriate.  I think that 0-RTT
MUST NOT be used for protection of RADIUS packets for the reason given.
In addition, it could be the fourth bullet in the list of requirements.

Section 3.3.1: The term "configured trust base" is not defined. I
suggest that this term be avoided altogether. I understand changes to
the set of configured trust anchors, but fresh CRLs are issued all the
time.  These two should probably not be talked about in the same bullet
since a fresh CRL does not impact every certification path that might be
active at a RADIUIS server.

Section 3.4: The second paragraphe ends with "determined as follows."  I
was expecting this to end with a colon, and then there to be a list of
bullets or some numbered items.

Section 7.5: You might want to point to draft-ietf-tls-extended-key-update,
which will eventually offer the ability to change the session keys
without shutting down the TLS session.


Food for thought:

Section 3.3: You might consider TLS-X.509-PKIX-PSK for TLS 1.3, which
gives certificate-based authentication and some protection against the
future invention of a quantum computer.  See draft-ietf-tls-8773bis,
which is in the RFC Editor's queue.


Nits:

Section 3.3.1: s/Certificate Authorities/Certification Authorities/

Section 3.3.1: s/longer than the validity span/beyond the validity period/

Section 3.3.1: s/(i.e. proxies)/(i.e., proxies)/

Section 3.3.1: s/trust chain check/certification path validation/

Section 3.7: s/(i.e. proxy)/(i.e., proxy)/

Section 7.7: s/e.g./e.g.,/