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

[Benoit Claise <[e-mail]>]

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