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 -- [email protected] To unsubscribe send an email to [email protected]
