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

Benoit Claise <> Mon, 12 October 2015 07:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 34B4E1A6F22; Mon, 12 Oct 2015 00:50:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mICwDCCr0mvG; Mon, 12 Oct 2015 00:50:35 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6FD221A6F38; Mon, 12 Oct 2015 00:50:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6769; q=dns/txt; s=iport; t=1444636234; x=1445845834; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=t3SbzoYl07T9GNPEEDwSzlqYViob5A9Zg1xZwm11U/U=; b=XAF0Oe+PZpiz0KKvWpGwsX4MIJ/xMKDj5O9lfzKdrkYLKJVi6MsmZMUz fXycD2Eo3pFGSrmVjKJjoiE5tbJ7JAsvymmus48WKpk268hRtmJtjp6YK HSndsZoOH9rt8I3OqaMY+g93w0ZNc5QweSprwIjINuFonMQr4N7vkrlkU k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.17,671,1437436800"; d="scan'208,217";a="612162071"
Received: from (HELO ([]) by with ESMTP; 12 Oct 2015 07:50:32 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id t9C7oVer016326; Mon, 12 Oct 2015 07:50:31 GMT
To: Simon Josefsson <>,,,, NETCONF <>
References: <>
From: Benoit Claise <>
Message-ID: <>
Date: Mon, 12 Oct 2015 09:50:20 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------030800050004050509040603"
Archived-At: <>
Subject: Re: [secdir] review of draft-ietf-netconf-call-home-11
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Oct 2015 07:50:37 -0000

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 
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. 
refers to RFC 6241 for the client.
So I believe that we're good with a single reference to RFC 6241 in this 

Regards, Benoit
> Thanks,
> /Simon