Subject: [netconf] Secdir early partial review of draft-ietf-netconf-crypto-types-10

From: Rifaat Shekh-Yusef via Datatracker <[email-masked]>
Date: Mon, 22 Jul 2019 19:56:49 -0700

Review is partially done. Another assignment may be needed to complete it.

Reviewer: Rifaat Shekh-Yusef
Review result: Not Ready

There is the open issue of the proper structure of this YANG model, which was 
discussed with the security ADs and IESG, and still to be discussed with IANA.

Meanwhile, I have the following comments:

Page 6, hash-algorithm_t
Why would you include SHA1 and indicate that it is obsolete? why not just drop it?

Page 8, hash-algorithm-t
Why would the default be 0, i.e. NONE?
I think you should select a minimum algorithm that would be considered acceptable as the default.

page 17, encryption-algorithm-t
Why would you include RC4 algorithms?

page 19, signature-algorithm-t
Why would you include dsa-sha1?

page 40, grouping symmetric-key-grouping, leaf hidden-key { nacm:default-deny-write
If I understand hidden-key, it is a key that is not accessible through this model. 
So, what is this meant to describe?

page 45, grouping symmetric-key-pair-with-cert-grouping, input { leaf subject...
The user of Subject field is discouraged, and the SAN field should be used instead.
Take a look at the following:
https://tools.ietf.org/html/rfc6125#section-4

---

From: Watson Ladd <[email-masked]>
Date: Mon, 22 Jul 2019 20:16:01 -0700

> I think you should select a minimum algorithm that would be considered acceptable as the default.

Along those lines why is RSA-1024 in there? The asymmetric algorithm
doesn't differentiate between encryption and signing or other more
exotic things, which I guess is defensible but raises some potential
gotchas. We also have an IANA registry for AEAD schemes: why not use
that? This would have avoided some omissions such as AES-SIV mode.

Lastly one nit: it's elliptic curve not elliptical curve.