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) > <[email protected]> wrote: > > 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 > > >> -----Original Message----- >> From: netmod <[email protected]> On Behalf Of Juergen Schoenwaelder >> Sent: 10 March 2020 12:19 >> To: Qin Wu <[email protected]> >> Cc: Balázs Lengyel <[email protected]>; >> '[email protected]' <[email protected]> >> Subject: Re: [netmod] Secdir last call review of draft-ietf-netmod- >> factory-default-14 >> >> 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: >>> 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 protected]] 代表 Balázs Lengyel >>> 发送时间: 2020年3月10日 19:59 >>> 收件人: '[email protected]' <[email protected]> >>> 主题: [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 protected]> >>> Sent: 2020. március 9., hétfő 20:15 >>> To: [email protected] >>> Cc: [email protected]; [email protected]; >>> [email protected] >>> 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. >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> [email protected] >>> 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/> >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
