Subject: [netconf] Comments on crypto types presentation

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 6 Apr 2020 14:39:08 +0000

Since we are running short on time at the VI, I want to register some comments on the list.

* I ultimately like option #3 to progress the base client-server work and see if the key gen feature is desired down the road (enough to pick it back up).

* Second, I prefer option #2 for the reasons discussed as well as because of the comment Jason raised that I think the identityref approach makes sense.

Joe

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Apr 2020 17:33:38 +0200

Just for clarification: If we do #3 now, we can still do #2 later?

If the answer is 'yes', then option #3 is attractive as we gain time
and hopefully implementation experience and we can add protocol
specific key generation RPCs in a second step. Otherwise, option #2
seems more attractive to me. In a TPM world, it seems key generation
on the device is somewhat essential to have.

/js

On Mon, Apr 06, 2020 at 02:39:08PM +0000, Joe Clarke (jclarke) wrote:
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 6 Apr 2020 15:50:51 +0000

>    Just for clarification: If we do #3 now, we can still do #2 later?
  
Yes.

---

From: Kent Watsen <[email-masked]>
Date: Mon, 6 Apr 2020 22:09:05 +0000

Hi Juergen (and Joe and Jason),

> Just for clarification: If we do #3 now, we can still do #2 later?

Yes, as far as we know, the “algorithm" id can be added later.
 
Assuming existing versioning rules (Sec 11 in RFC 7950), the “algorithm” node would have to be added then as "mandatory false", which might be okay.  Of course, the YANG-versioning work (in NETMOD WG) should be published by then so, in the worst case (i.e., it needs to be mandatory true), the YANG module could legally introduce the non-backwards-compatible change.

> specific key generation RPCs in a second step.

Indeed, time-to-market vs completeness.  However everyone should be aware that the deferral would likely be  "a few years", if not more.

I’m personally okay with that, and perhaps even prefer it, since it more quickly gets the monkey off my back.  

Devil’s advocate position: not supporting keygen would be a disservice to the industry as whole, and there’s something to be said for striking while the iron is hot.

PS: regarding enum vs identityref.  Option 1 could also use identityref…and, in fact, it did before.  The reason Option 1 changed to using an enum was so that a set “value” could be associated with each algorithm.  That said, the need to set a value was never clearly explained and, IMO, doesn’t exist.  My only point is, don’t let enum-vs-identity be the key differentiator in thinking about Option 1-vs-2.   

Kent // contributor

> Otherwise, option #2

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 6 Apr 2020 23:02:43 +0000

> On Apr 6, 2020, at 18:09, Kent Watsen <[email-masked]> wrote:
> 

I agree that having it is a big value.  That said, I’ve watched this work go from something that seems like a quick close to something very drawn out.  To that end, it might be best to ratify the client-server work as it is now and add on later since it seems like that would be possible.

Plus, based on your comments today, it could be that others will step up who may have a stronger motivation to provide this to the industry.

Joe

---

From: tom petch <[email-masked]>
Date: Tue, 7 Apr 2020 09:18:36 +0000

Joe

Could you clarify for the benefit of those on the mailing list what is
1
2
3
...?
Tom Petch

________________________________________
From: netconf <[email-masked]> on behalf of Joe Clarke (jclarke) <jclarke=[email-masked]>
Sent: 06 April 2020 15:39

Joe

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Tue, 7 Apr 2020 10:26:30 +0000

On Apr 7, 2020, at 05:18, tom petch <[email-masked]<mailto:[email-masked]>> wrote:

Joe

Sorry.  See slides 6-8 in Kent’s “Status and Issues for the ‘Client-Server’ Suite of Drafts at https://datatracker.ietf.org/meeting/interim-2020-netconf-01/session/netconf.

1. Define as much as possible into crypto-types
2. Define everything in protocol-specific layers
3. Fold trying to enable servers to generate keys

Joe

1
2
3
....?
Tom Petch

________________________________________
From: netconf <[email-masked]<mailto:[email-masked]>> on behalf of Joe Clarke (jclarke) <jclarke=[email-masked]<mailto:jclarke=[email-masked]>>
Sent: 06 April 2020 15:39

Joe
_______________________________________________
netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf