Ballot for draft-ietf-opsawg-secure-tacacs-yang
Discuss
Yes
No Objection
Recuse
No Record
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
Section 6: Any mention of raw private key, epsk, shared secret MUST be protected from disclosure (i.e. encrypted in transit, and in storage). Any configuration which specifies TLS1.3 cipher suites, epsk hash, epsk KDFs MUST be protected from modification - change of these can be a downgrade attack. While I see mention of 'shared-secret', I see nothing about epsk, raw private key, or TLS1.3 cipher suite negotiation.
Thanks to Robert Sparks for their secdir review. Section 4, grouping tls13-epsk: 'Selfie-style reflection' attacks? Reference?
# Internet AD comments for draft-ietf-opsawg-secure-tacacs-yang-12 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Nits ### S3 * "The time on the most recent occasion" -> "The time of the most recent occasion"
I support Deb's dicsuss. All security parameters are sensitive - if modified to weaker or broken algorithms that are still supported, this could be used to downgrade connections to a lesser security level.
Thank you to Ines Robles for the GENART review.
Thanks for addressing my previous DISCUSS point (see https://mailarchive.ietf.org/arch/msg/opsawg/9zoIrp-e4ghq8EVlvQSkwrhvJfc/ ) ## COMMENTS (non-blocking) ### Section 4 I will let the SEC ADs have the final word of course, but I wonder whe the domain-name leaf is not mandatory ? I.e., the client must check whether the server certificate matches the expected SN of the certificate. Should the YANG module also include which cipher-suite was actually negotiated ? ### Appendix B Thanks for the IPv6 examples ;-)
I'm the editor of this spec.