Re: [secdir] [Netconf] review of draft-ietf-netconf-call-home-11

Simon Josefsson <simon@josefsson.org> Fri, 16 October 2015 11:28 UTC

Return-Path: <simon@josefsson.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790B21A9091; Fri, 16 Oct 2015 04:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMAIkb2sdt_C; Fri, 16 Oct 2015 04:28:52 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE8881A9081; Fri, 16 Oct 2015 04:28:51 -0700 (PDT)
Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t9GBSWp1016921 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 16 Oct 2015 13:28:33 +0200
Date: Fri, 16 Oct 2015 13:28:31 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Kent Watsen <kwatsen@juniper.net>
Message-ID: <20151016132831.64b45561@latte.josefsson.org>
In-Reply-To: <D24136E6.E6AAA%kwatsen@juniper.net>
References: <8737xnp0rm.fsf@latte.josefsson.org> <561B663C.7080408@cisco.com> <D24136E6.E6AAA%kwatsen@juniper.net>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/XZb1.S/1zz0iQDF6+s8p5dP"; protocol="application/pgp-signature"
X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/2wPwMcby3DKyNhvTIRubx2WT80M>
Cc: Benoit Claise <bclaise@cisco.com>, NETCONF <netconf@ietf.org>, "draft-ietf-netconf-call-home.all@ietf.org" <draft-ietf-netconf-call-home.all@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] [Netconf] review of draft-ietf-netconf-call-home-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Oct 2015 11:28:53 -0000

Hello.

Re 1: Thank you for clarification.  I don't believe there is any need
to repeat text from a normative reference.

Re 2: Benoit's suggestion would resolv the concern for me.

Thanks,
/Simon

> Hi Simon,
> 
> 
> Regarding your two comments:
> 
> 1. Are non-certificate-based TLS out of scope for NETCONF/RESTCONF?
> 
> Yes or, more specifically, both NETCONF over TLS and and RESTCONF
> restrict TLS to certificates.  The relevant text is in RFC 7589,
> Section 1 and draft-ietf-netconf-restconf-07, Section 2.2.   Do you
> think there should be a note in this draft stating this as well?
> 
> 2. Section 2 says 'The term "NETCONF/RESTCONF client" can refer to
> the [RFC6241], Section 1.1 "client".'
> 
> Does Benoit's suggestion to replace "can refer" with "refers" satisfy
> the language vagueness issue?   - And also, are you satisfied with
> having the single reference to RFC6241, since RESTCONF pulls the term
> from RFC6241 as well?
> 
> 
> Thanks
> Kent
> 
> 
> From: Benoit Claise <bclaise@cisco.com<mailto:bclaise@cisco.com>>
> Date: Monday, October 12, 2015 at 3:50 AM
> To: Simon Josefsson
> <simon@josefsson.org<mailto:simon@josefsson.org>>,
> "iesg@ietf.org<mailto:iesg@ietf.org>"
> <iesg@ietf.org<mailto:iesg@ietf.org>>,
> "secdir@ietf.org<mailto:secdir@ietf.org>"
> <secdir@ietf.org<mailto:secdir@ietf.org>>,
> "draft-ietf-netconf-call-home.all@tools.ietf.org<mailto:draft-ietf-netconf-call-home.all@tools.ietf.org>"
> <draft-ietf-netconf-call-home.all@tools.ietf.org<mailto:draft-ietf-netconf-call-home.all@tools.ietf.org>>,
> "netconf@ietf.org<mailto:netconf@ietf.org>"
> <netconf@ietf.org<mailto:netconf@ietf.org>> Subject: Re: [Netconf]
> review of draft-ietf-netconf-call-home-11
> 
> Hi Simon,
> 
> Thanks for your review.
> One comment below.
> 
> Hi.
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> I believe the document is ready.
> 
> One main security concern is the reversal of roles that this document
> introduce, but letting TCP clients act as TLS/SSH servers, and vice
> versa, is not unheard of.  As long as proper peer authentication is
> performed, and other parts of the security protocols are properly
> performed, I see no fundamental problem with this.  I'm sure some
> implementations will need to be tweaked to deal with this, and
> terminology might confusing at times.  The 'Security Considerations'
> section does a good job discussing this, and some other issues too.
> 
> Two minor questions:
> 
> 1) Are non-certificate-based TLS out of scope for NETCONF/RESTCONF?  I
> see no discussion of it in this draft, and text in the document
> implicitly assumes host keys (SSH) or certificates (TLS) are used.
> Think about TLS-PSK for example, which seems like a relevant idea for
> embedded devices.  This may not be the document to adress this, but if
> there is work towards that goal already, it might be useful to align
> this document with that.
> 
> 2) Section 2 says 'The term "NETCONF/RESTCONF client" can refer to the
> [RFC6241], Section 1.1 "client".'.  Shouldn't this say the term may
> refer to a RESTCONF client and reference draft-ietf-netconf-restconf?
> Or is that not intentional?  The use of the word 'can' make this text
> vague to me.  The previous section (1.5) says that 'NETCONF/RESTCONF'
> is an abbrevation for 'the NETCONF or the RESTCONF'.  The same comment
> applies to section 3.  Maybe this is a misunderstanding on my side,
> but the text confused me so it may be useful to resolve.
> 
> I mentioned this point in my AD review
> (http://www.ietf.org/mail-archive/web/netconf/current/msg10535.html).
> I now realize that I made a typo in my email: NETCONF/RESTCONF
> client" can refers to the RFC 6241 section 1.1 "client" This should
> read:  "NETCONF/RESTCONF client" refers to the RFC 6241 section 1.1
> "client" Ditto for NETCONF/RESTCONF server. This takes care of the
> confusing "can" word. Thanks for spotting that.
> 
> Regarding the draft-ietf-netconf-restconf reference now.
> https://tools.ietf.org/html/draft-ietf-netconf-restconf-07#section-1.4.1
> refers to RFC 6241 for the client. So I believe that we're good with
> a single reference to RFC 6241 in this draft.
> 
> Regards, Benoit
> 
> Thanks,
> /Simon
> 
>