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]
> <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]
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
