Hi Deb, Following up on this thread.
> On Sep 8, 2025, at 5:26 PM, Mahesh Jethanandani <[email protected]> > wrote: > > Hi Deb, > >> On Aug 7, 2025, at 3:14 PM, Deb Cooley via Datatracker <[email protected] >> <mailto:[email protected]>> wrote: >> >> Deb Cooley has entered the following ballot position for >> draft-ietf-opsawg-secure-tacacs-yang-13: 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-secure-tacacs-yang/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I've edited my ballot to be 'no objection'. >> >> I'm gathering that it not the Yang data model's responsibility to protect >> (particularly) sensitive values in storage, but only in transport. Given >> that >> raw private keys, epsk, and shared secrets for TLS connections are apparently >> stored in Yang data models in plaintext form, that there should be something >> in >> the Security Considerations as a warning. > > That is not true. It is the responsibility of the YANG module to specify how > a particularly sensitive attribute is protected in storage. Storing private > keys, or shared secrets are expected to be protected using > nacm:default-deny-all, where nacm refers to NACM [RFC8341]. In addition, > sensitive data is expected to be stored as a cryptographic hash. This > document refers to and uses the groupings defined in RFC 9642 that defines in > Section 4 how the encrypting of keys should happen in configuration. Does this explanation make sense? > > Are you seeing something in this document that gives you another impression? The only other thing I can think of is the ’shared-secret’ leaf which has been defined as a string. It has been called out in the Security Considerations Section, and recommended for protection using NACM. Are you suggesting that this should be stored as a cryptographic hash? > > Thanks. > >> >> -------------------------------------- >> Thanks to Robert Sparks for their secdir review. >> >> Section 4, grouping tls13-epsk: 'Selfie-style reflection' attacks? >> Reference? >> >> >> > > > Mahesh Jethanandani > [email protected] <mailto:[email protected]> Mahesh Jethanandani [email protected]
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
