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

Simon Josefsson <simon@josefsson.org> Wed, 07 October 2015 07:59 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 101781A9066; Wed, 7 Oct 2015 00:59:35 -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 sctESw6TVr0H; Wed, 7 Oct 2015 00:59:32 -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 CA21D1A9088; Wed, 7 Oct 2015 00:59:30 -0700 (PDT)
Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t977xQ8Y005768 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 7 Oct 2015 09:59:27 +0200
X-Hashcash: 1:22:151007:iesg@ietf.org::Ds+EB8PhX+CNE3BZ:ddz
X-Hashcash: 1:22:151007:secdir@ietf.org::80TxBABQtz8eqYe2:c+Nu
X-Hashcash: 1:22:151007:draft-ietf-netconf-call-home.all@tools.ietf.org::cNNc87ViBNv/gt2S:yCiK
From: Simon Josefsson <simon@josefsson.org>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-netconf-call-home.all@tools.ietf.org
OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt
Date: Wed, 07 Oct 2015 09:59:25 +0200
Message-ID: <8737xnp0rm.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; 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/5Hni0hR2tc2GEqB7ZngYUvWnuwk>
Subject: [secdir] 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: Wed, 07 Oct 2015 07:59:35 -0000

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.

Thanks,
/Simon