Subject: Re: [netmod] Secdir last call review of draft-ietf-netmod-factory-default-14

From: Qin Wu <[email-masked]>
Date: Tue, 10 Mar 2020 12:13:51 +0000

Thanks Balazs for heads up. I think the security guideline we are currently following is one defined in the following link:
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines
If it is a issue, I believe it applies to all YANG related documents.

-Qin
-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Balázs Lengyel
发送时间: 2020年3月10日 19:59
收件人: [email-masked]' <[email-masked]>
主题: [netmod] FW: Secdir last call review of draft-ietf-netmod-factory-default-14

As an author of netmod drafts I would like to see some general guidance on this issue. Can someone help please.
Balazs

-----Original Message-----
From: Stephen Kent via Datatracker <[email-masked]> 
Sent: 2020. március 9., hétfő 20:15
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Secdir last call review of draft-ietf-netmod-factory-default-14

Reviewer: Stephen Kent
Review result: Has Issues

SECDIR review of draft-ietf-netmod-factory-default-14

Section 6, Security Considerations, calls for use of SSH (RFC 6242) with NETCONF and HTTPS (RFC 8446) with RESTCONF. The TLS reference is current, citing TLS v1.3. However, RFC 6242 is a document that describes how to use SSH with NETCONF. That document, in turn, cites RFC 4254, and that RFC cites RFC
4253 for a description of SSH. 4253 is a very much out of date document; the integrity and key management algorithms in the original RFC have been updated 3 times (6668, 8268, and 8332). The encryption algorithms cited in 4253 are all outdated. This discussion of SSH security for use with NETCONF, based on the one citation, seems to be inconsistent with current IETF crypto guidelines.
This is a problem that the net management area should address before this document is approved.

The discussion of how a factory-reset RPC may isolate a device, is good, as is the warning about not relying on this RPC to prevent recovery of security-sensitive data from NV storage.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Mar 2020 13:19:23 +0100

Hi,

if secdir people believe RFC 6242 needs to be revised or updated, then
this is a separate work item for the NETCONF working group to
consider. I do not think that such an update should gate any data
models currently in the pipeline. (I am not even sure such an update
is strictly needed since if we go there, we constantly need udpates,
but that is then a NETCONF discussion.)

/js

On Tue, Mar 10, 2020 at 12:13:51PM +0000, Qin Wu wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
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: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 10 Mar 2020 13:38:22 +0000

I basically agree with Juergen.

I have also raised this with the security ADs to try and find a path to resolve this.

Thanks,
Rob

> From: netmod <[email-masked]> On Behalf Of Juergen Schoenwaelder
> Sent: 10 March 2020 12:19
> To: Qin Wu <[email-masked]>
> Cc: Balázs Lengyel <balazs.lengyel=[email-masked]>;
> [email-masked]' <[email-masked]>
> Subject: Re: [netmod] Secdir last call review of draft-ietf-netmod-
> factory-default-14
> 
> Hi,
> 
> this is a separate work item for the NETCONF working group to consider. I
> do not think that such an update should gate any data models currently in
> the pipeline. (I am not even sure such an update is strictly needed since
> if we go there, we constantly need udpates, but that is then a NETCONF
> discussion.)
> 
> /js
> 
> > Thanks Balazs for heads up. I think the security guideline we are
> currently following is one defined in the following link:
> > Section 6, Security Considerations, calls for use of SSH (RFC 6242)
> > with NETCONF and HTTPS (RFC 8446) with RESTCONF. The TLS reference is
> > current, citing TLS v1.3. However, RFC 6242 is a document that
> > describes how to use SSH with NETCONF. That document, in turn, cites
> > RFC 4254, and that RFC cites RFC
> > 4253 for a description of SSH. 4253 is a very much out of date document;
> the integrity and key management algorithms in the original RFC have been
> updated 3 times (6668, 8268, and 8332). The encryption algorithms cited in
> 4253 are all outdated. This discussion of SSH security for use with
> NETCONF, based on the one citation, seems to be inconsistent with current
> IETF crypto guidelines.
> > The discussion of how a factory-reset RPC may isolate a device, is good,
> as is the warning about not relying on this RPC to prevent recovery of
> security-sensitive data from NV storage.
> >
> >
> >

---

From: Kent Watsen <[email-masked]>
Date: Tue, 10 Mar 2020 22:09:17 +0000

Thanks Rob and Juergen. 

I agree as well, as it doesn’t make sense to force higher-level protocol layers to publish updates whenever a lower-level layer publishes an update and thereby “obsoletes” the previous protocol layer version.  I put “obsolete” in quotes because I think its generally understood that the previous protocol version is not obsolete in a real-world sense for many years to come.

FWIW, RFC 8040 says:

   RESTCONF does not require a specific version of HTTP.  However, it is
   RECOMMENDED that at least HTTP/1.1 [RFC7230] be supported by all
   implementations.   

   <Note: HTTP/1.1 is NOT obsoleted by HTTP 2.0 (RFC 7540)>

And:

   A RESTCONF server MUST support the Transport Layer Security (TLS) 
   protocol [RFC5246]  

   <Note: RFC 5246 (TLS 1.2) is obsoleted by RFC 8446 (TLS 1.3)>

Kent

> On Mar 10, 2020, at 9:38 AM, Rob Wilton (rwilton) <rwilton=[email-masked]> wrote:
>