Mahesh Jethanandani has entered the following ballot position for draft-ietf-opsawg-tacacs-tls13-21: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Russ Housley for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/cNyvkP_-A4zahKP-Ln_-DgozZzg). In general, found the document easy to read. I have some minor COMMENT and NIT. ------------------------------------------------------------------------------- COMMENT ------------------------------------------------------------------------------- No reference entries found for these items, which were mentioned in the text: [draft-ietf-radext-tls-psk] and [I-D.ietf-uta-require-tls13]. Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term "man"; alternatives might be "individual", "people", "person" ------------------------------------------------------------------------------- NIT ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 3.4, paragraph 1 > Deploying TLS certificate-based uthentication correctly will > considerably improve the security of TACACS+ deployments. It is > essential for implementers and operators to understand the > implications of a TLS certificate-based authentication solution, > including the correct handling of certificates, Certificate > Authorities (CAs), and all elements of TLS configuration. For > guidance, start with [BCP195]. s/uthentication/authentication/ Section 5.1.6, paragraph 0 > The use of wildcards in TLS server identities creates a single point > of failure: a compromised private key of a wildcard certificate > impacts all servers using it. Their use MUST follow recommendations > of Section 7.1 of [RFC9525]. Operators MUST ensure that the wildcard > is limited to a subdomain dedicated solely to TLS TACACS+ servers. > Further, operators MUST ensure that the TLS TACACS+ servers covered > by a wildcard certificate MUST be impervious to redirection of > traffic to a different server (for example, due to MiTM attacks or > DNS cache poisoning). Though expanded later, would prefer that MiTM is expanded here, as it is the first use of the acronym. Uncited references: [TLSCSREC]. Section 3.6, paragraph 2 > lient and servers MUST operate with regards to the obfuscation mechanism. Pe > ^^^^^^^^^^^^^^^ Use "in regard to", "with regard to", or more simply "regarding". _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
