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

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Kent,

Thanks for your prompt reply and the comments.

As my corporate mail agent is not the most suitable one, please see below for EVY>

While my ballot is not blocking your document, I will welcome the discussion on the “key rollover” and “not valid before” topics.

Regards

-éric

From: Kent Watsen <[e-mail]>
Date: Monday, 29 January 2024 at 16:14
To: Eric Vyncke <[e-mail]>
Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Mahesh Jethanandani <[e-mail]>
Subject: Re: Éric Vyncke's Abstain on draft-ietf-netconf-crypto-types-29: (with COMMENT)

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?

EVY> indeed the author can do nothing about it, but usually there are some justifications about why it is ‘proposed standard’.


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?

EVY> Yes, and thanks for the explanations below. I understand the point of view.

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.

EVY> if this is only for authenticating *TO* a peer, then we agree. It was unclear to me whether authentication *BY* a peer was also in scope.

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?

EVY> in many systems, it is nearly impossible to change the keys/passwords everywhere simultaneously (notably because some systems could be unreachable).
EVY> I.e., two keys/passwords can be used simultaneously for a short period of time to allow *all* peers to synchronize the credentials.
EVY> typical case with certificates and also IPsec key rollover.
EVY> for a OPS WG document, I would expect those operational considerations taken into account.


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?

EVY> Very similar to the discussion about roll-over. If a node has two certificates (e.g., 1 day before the expiration, a new one is requested/installed),
EVY> which one should be used? Especially, if one is not *yet* valid.


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