> On Sep 22, 2025, at 2:50 AM, Deb Cooley <[email protected]> wrote: > > 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.
That is fair comment. I think we can do better next time in referencing SC (where they are already defined) or defining them (if they are not) for the imported nodes into drafts that use them. > > 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] > <mailto:[email protected]>> wrote: >> Hi Deb, >> >>> On Sep 21, 2025, at 10:00 AM, Deb Cooley <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> inline w/ [DC] >>> >>> On Mon, Sep 8, 2025 at 8:26 PM Mahesh Jethanandani <[email protected] >>> <mailto:[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. >>> >>> [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] <mailto:[email protected]> >> >> Mahesh Jethanandani >> [email protected] <mailto:[email protected]> >> >> >> >> >> >> Mahesh Jethanandani [email protected]
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
