OK I see now. The language used in SC isn't at all what I understand as a security person. I'd prefer that more direct language is used, but that ship has sailed long ago.
Encryption w/ a KEK and/or public/private key pair is fine, and indeed what I would expect a client to use. (definitely not cryptographic hashes) Deb On Sun, Sep 21, 2025 at 6:53 PM Mahesh Jethanandani <[email protected]> wrote: > Hi Deb, > > On Sep 21, 2025, at 10:00 AM, Deb Cooley <[email protected]> wrote: > > 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. > > > [mj] What might help is to look at the full tree diagram in Appendix C, > which mentions the raw-private-key used by the client. Here is a snippet of > the part of the tree that defines raw-private-key. > > | +--:(raw-public-key) {tlsc:client-ident-raw-public-key}? > | | +--rw raw-private-key > | | +--rw (inline-or-keystore) > > The YANG module is essentially importing the grouping from RFC 9645 > (Groupings for TLS Clients and Servers) which in turn imports the grouping > from RFC 9642 (A YANG Data Model for a Keystore). > > > 2. Are shared secrets (and presumably private keys) merely stored in > access controlled locations? How does this prevent extraction and exposure > of those values? > > > [mj] It is the Keystore module that defines how private-keys are encrypted > and stored. See Section 4 in RFC 9642. > > Let me know if you have any questions. > > Thanks > > > >> >> 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] >> > > > Mahesh Jethanandani > [email protected] > > > > > > >
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
