Re: [netconf] Éric Vyncke's Abstain on draft-ietf-netconf-crypto-types-29: (with COMMENT)

[Kent Watsen <[e-mail]>]

Hi Éric,

Thank you for your review.
Please find below my responses to your comments.

Kent


> On Jan 29, 2024, at 9:05 AM, Éric Vyncke via Datatracker <[e-mail]> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-netconf-crypto-types-29: Abstain
> 
> 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-netconf-crypto-types/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for the work done.
> 
> The shepherd's writeup would benefit from a better justification of the
> intended status.

There is not much I can do about the shepherd writeup…  ;)

The document’s header says the Intended Status is "Standards Track”.
  - is this okay?



> Is there a reason why there are several NETCONF WG crypto-related I-Ds rather
> than a single one ?

Do you mean the suite of documents - 9 documents in total?

I guess because each document has its focus and can be referenced by other
documents individually.

For instance, other WGs have documents that reference the “keystore” document,
while others reference the “tis-client-server” draft.  If there were a single document,
those references would be too course.  Makes sense?


> I was about to DISCUSS the following point but balloting ABSTAIN as I am unsure
> about the use case: the model has cleartext and encrypted passwords (the latter
> is a hint that the password can be decrypted back to cleartext) but what about
> password hashes if the remote party should also be authenticated over a
> protected channel by sending a clear text password ?

The password documented here is for when configuring a server to connect to a
remote system, in which case the cleartext password is needed.

Elsewhere (in the "ssh-client-server" and "http-client-server" drafts), there are passwords
used for local users (i.e., users logging into the server itself).  The configuration for
those passwords use the “crypt-hash” type from RFC 7317.

Makes sense?


> Another near-DISCUSS point: what about key rollover when 2 keys/passwords could
> be used ?

What do you mean?  Can you say some more?


> As in another document, it is nice to have a certificate expiration date but
> what about a 'not valid before' date ? This is similar to the previous point of
> key rollover.

The “certificate-expiration” notification is an asynchronous  message used to alert
when a certificate is about to become invalid.

AFAICT, there isn’t a need for an asynchronous notification that a certificate isn’t
valid yet, or even when a cert is about the become valid, and hence not notification
is defined for this case - make sense?


> Please add a reference to `rainbow attacks`.

A rainbow attack is used to crack hashed passwords. 

As mentioned above, RFC 7317 defines the “crypt-hash” type, which is used by
other documents in this document-series (specifically the "ssh-client-server” and
"http-client-server” drafts).

The “password-grouping” defined in this document isn't for local users, where 
hashed-passwords would be used, but rather to configure clients to connect to
remote systems, where a cleartext password is needed.

I don’t understand why this document might reference rainbow attacks.  Perhaps
RFC 7317 could’ve referenced rainbow attacks, but it didn’t.

Please let me know if there is anything I can do to improve the text!


Thanks,
Kent