Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT)

[Kathleen Moriarty <[e-mail]>]

Kathleen Moriarty has entered the following ballot position for
draft-ietf-rtgwg-yang-key-chain-20: 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.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for your work on this draft.  There is one outstanding issue from
the SecDir review that may require some updated text to resolve.  It
seems use of the key wrap method in RFC5649 requires more guidance for
implementations to use it with this YANG module.  It's good to know that
this is in use for other modules, so having a clear reference either to
another draft or the text being in this draft for later reference would
be helpful.

In looking at this text within the draft, I think it would be better to
pull the text out of the Security Considerations section and into an
earlier section of the draft.  It's better to introduce this prior to
enumerating security considerations for the draft since this something
that would be implemented.  Then security considerations should mention
the considerations of using this option versus just what's in NACM.

You have the text:

  When configured, the key-strings can be encrypted using the AES Key
   Wrap algorithm [AES-KEY-WRAP].  The AES key-encryption key (KEK) is
   not included in the YANG model and must be set or derived
independent
   of key-chain configuration.  When AES key-encryption is used, the
   hex-key-string feature is also required since the encrypted keys
will
   contain characters that are not representable in the YANG string
   built-in type [YANG].  AES key-encryption MAY be used for added key
   security in situations where the NETCONF Access Control Mode is not
   available.

I think it's pretty straightforward after looking at RFC5649, but maybe
more text would be helpful to clarify for implementers.  This might mean
more text from 5649 on what gets placed in the YANG data model where you
have already allocated for this or including an example.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for working through the SecDir review and making the suggested
updates.

Since the following text int he Security Considerations section is a
recommendation, IMO it would be better to drop "or otherwise obfuscated"
from the sentence as encrypting the keys really should be the
recommendation.  Can we make this update?

   It is RECOMMENDED that keys be encrypted or otherwise obfuscated
when
   stored internally on a network device supporting this specification.

If obfuscation is what happens more often in practice, maybe mention this
as a fallback from the recommendation, but not make them sound
equivalent?