Hello Deb, Many thanks for taking the time and for the comments and insights.
Please see inline: From: Deb Cooley via Datatracker <nore...@ietf.org> Date: Tuesday, 24 June 2025 at 14:11 To: The IESG <i...@ietf.org> Cc: draft-ietf-opsawg-tacacs-tl...@ietf.org <draft-ietf-opsawg-tacacs-tl...@ietf.org>, opsawg-cha...@ietf.org <opsawg-cha...@ietf.org>, opsawg@ietf.org <opsawg@ietf.org>, mohamed.boucad...@orange.com <mohamed.boucad...@orange.com>, Joe Clarke (jclarke) <jcla...@cisco.com>, Joe Clarke (jclarke) <jcla...@cisco.com> Subject: Deb Cooley's No Objection on draft-ietf-opsawg-tacacs-tls13-23: (with COMMENT) Deb Cooley has entered the following ballot position for draft-ietf-opsawg-tacacs-tls13-23: 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: ---------------------------------------------------------------------- I support Ketan's discuss. This protocol is in wide use, it would be useful to have the whole protocol be PS. Thanks to Russ Housley for their secdir review. Section 3, last sentence: This draft is almost in the RFC Editor's queue. It would be better if it could be a normative reference, since it is exactly what you are trying to specify here. Section 3.4.1: Sometimes these (both cert path validation and revocation checking) can be quite hard. Many implementations of TLS allow a bypass in the case of network latency issues. And while it pains me to say this as 'a PKI person', you may need to consider whether there needs to be an allowance for a bypass. What happens if there are network issues blocking chains or OCSP? Is there a reference for this abort? Would prefer not to define a TLS abort behaviour inside this doc. Section 5.1.2: There is an 'early data extension' that the client could include to enable the ability to send early data. Perhaps the statement 'A TLS client or server MUST NOT include the "early_data" extension. See Section 2.3 and 4.2.10 of [RFC8446] for security concerns.' or something similar could be added. Agreed, will add. Section 5.1.5: 'subject to eavesdropping' because SNI is sent in the clear in the Client Hello? Would it be more direct to say something like, 'the TLS SNI extension is part of the TLS client hello, which is sent in cleartext and is, therefore...' That might make for an awkward sentence, which could be split into two sentences. Agreed, clarified the cleartext nature of the client hello. Section 5.2: Nit: just be sure the (TBD) is properly flagged for IANA. Section 5.3: I'm not sure it is necessary to throw STARTTLS 'under the bus' as it were. The point can be made w/out it (especially since no reference to STARTTLS is supplied). I'd be happy to help with the re-write. [https://en.wikipedia.org/wiki/Throw_under_the_bus] Agreed, we’ve removed references to STARTTLS.
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
