Hi Paul, Many thanks for the review.
This section also came up in another recent review, we have clarified that the issue is that the client hello is in cleartext. Of course, this doesn’t address your real point, which is that it doesn’t matter that it is in cleartext as the information is available elsewhere, and you are correct, however we judged that as we included its configurability in deployments, that it’s transmission in plaintext is worth raising. If that irks still, please let us know. From: Paul Wouters via Datatracker <nore...@ietf.org> Date: Wednesday, 25 June 2025 at 01:59 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: Paul Wouters' Yes on draft-ietf-opsawg-tacacs-tls13-23: (with COMMENT) Paul Wouters has entered the following ballot position for draft-ietf-opsawg-tacacs-tls13-23: Yes 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 for a clear document. I just have one comment: 5.1.5. TLS Server Name Indicator (SNI) Operators should be aware that the TLS SNI extension is part of the TLS client hello and is, therefore, subject to eavesdropping. Also see Section 11.1 of [RFC6066]. I am not sure why this really matters? I presume the name is already in public DNS and/or reverse DNS and is probably already well known? It will be using a new tacacss well-known port so the name isn't needed to leak information that the connection is tacacs. Also, if it mattered, since the server is likely dedicated to this purpose, why use SNI? One could just not use it, as the target server doesn't need to vhost demux the HTTPS request anyway? And finally, one could use ECH to protect against SNI sniffing, if it really mattered.
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
