inline w/ [DC] On Mon, Sep 8, 2025 at 8:26 PM Mahesh Jethanandani <[email protected]> wrote:
> Hi Deb, > > On Aug 7, 2025, at 3:14 PM, Deb Cooley via Datatracker <[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. > [DC] Isn't NACM just specifying access controls? Is that actually how keys - shared secrets and private keys (which aren't mentioned at all) are stored? One cannot store shared secrets and private keys as cryptographic hashes, because they have to be available in plaintext to be used (hashes are one way functions, once the value is hashed, you can't go back to the pre-hashed value). [DC] I guess my questions are these: 1. Why are private keys never mentioned when raw public keys and certificates are? There obviously need to be private keys, or one can't perform the certificate validate part of TLS 1.3. Seems odd. 2. Are shared secrets (and presumably private keys) merely stored in access controlled locations? How does this prevent extraction and exposure of those values? > > Are you seeing something in this document that gives you another > impression? > > Thanks. > > > -------------------------------------- > Thanks to Robert Sparks for their secdir review. > > Section 4, grouping tls13-epsk: 'Selfie-style reflection' attacks? > Reference? > > > > > > Mahesh Jethanandani > [email protected] > > > > > > >
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
