top posting.... modification and disclosure are not the same. Default deny write still allows reading, no?
Deb On Mon, Jul 7, 2025 at 7:24 AM <mohamed.boucad...@orange.com> wrote: > Hi Deb, > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Deb Cooley via Datatracker <nore...@ietf.org> > > Envoyé : lundi 7 juillet 2025 12:54 > > À : The IESG <i...@ietf.org> > > Cc : draft-ietf-opsawg-secure-tacacs-y...@ietf.org; opsawg- > > cha...@ietf.org; opsawg@ietf.org; jcla...@cisco.com; > > jcla...@cisco.com > > Objet : Deb Cooley's Discuss on draft-ietf-opsawg-secure-tacacs- > > yang-13: (with DISCUSS and COMMENT) > > > > > > Deb Cooley has entered the following ballot position for > > draft-ietf-opsawg-secure-tacacs-yang-13: Discuss > > > > 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.) > > > > -------------------------------------------------------------------- > > DISCUSS: > > -------------------------------------------------------------------- > > > > Section 6: Any mention of raw private key, epsk, shared secret MUST > > be > > protected from disclosure (i.e. encrypted in transit, and in > > storage). Any > > configuration which specifies TLS1.3 cipher suites, epsk hash, epsk > > KDFs MUST > > be protected from modification - change of these can be a downgrade > > attack. > > While I see mention of 'shared-secret', I see nothing about epsk, > > raw private > > key, or TLS1.3 cipher suite negotiation. > > [Med] The text calls the parent nodes, not child ones. All those nodes you > cited fall under: > > 'client-identity' and 'server-authentication': Any modification to a > key or reference to a key may dramatically alter the implemented > security policy. For this reason, the NACM extension "default- > deny-write" has been set. > > > > > > > -------------------------------------------------------------------- > > COMMENT: > > -------------------------------------------------------------------- > > > > Thanks to Robert Sparks for their secdir review. > > > > Section 4, grouping tls13-epsk: 'Selfie-style reflection' attacks? > > Reference? > > > > [Med] The reference is already provided in the text: > > > identities to mitigate Selfie-style reflection attacks."; > reference > "RFC 9258: Importing External Pre-Shared Keys (PSKs) for > TLS 1.3, Section 5.1 "; > > 5.1 of 9258 has the following: > > ImportedIdentity.context MUST include the context used to determine > the EPSK, if any exists. For example, ImportedIdentity.context may > include information about peer roles or identities to mitigate > Selfie-style reflection attacks [Selfie]. See Appendix A for more > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > details. > > ____________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > >
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
