Subject: [Netconf] draft-ietf-netconf-call-home: one week review period

From: Benoit Claise <[email-masked]>
Date: Tue, 15 Dec 2015 19:12:56 +0100

Dear all,

Between the version 11, initially transmitted to the IESG, and the 
latest version 15, addressing all the DISCUSSes, there were a series of 
changes.
I propose a one week review for those changes 
<https://www.ietf.org/rfcdiff?url1=draft-ietf-netconf-call-home-11&url2=draft-ietf-netconf-call-home-15>, 
before I sent this document to the RFC-editor queue.
If you have a problem with those changes, speak up now.

Regards, Benoit

---

From: Kent Watsen <[email-masked]>
Date: Tue, 15 Dec 2015 21:34:49 +0000

Funny or sad, depending on how you look at it, but I just now I found a typo in C1:

    - to listen a different port.
    + to listen to a different port.

Should we let the RFC Editor catch it?

Kent

From: Netconf <[email-masked]<mailto:[email-masked]>> on behalf of Benoit Claise <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, December 15, 2015 at 1:12 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Netconf] draft-ietf-netconf-call-home: one week review period

Dear all,

Between the version 11, initially transmitted to the IESG, and the latest version 15, addressing all the DISCUSSes, there were a series of changes.
I propose a one week review for those changes<https://www.ietf.org/rfcdiff?url1=draft-ietf-netconf-call-home-11&url2=draft-ietf-netconf-call-home-15>, before I sent this document to the RFC-editor queue.
If you have a problem with those changes, speak up now.

Regards, Benoit

---

From: "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>
Date: Tue, 15 Dec 2015 21:47:04 +0000

Hi Kent,

yes, you can. RFC Editor is actually very good to catch such bugs.
During this review on the maillist we may find also other bugs.

Mehmet

From: Netconf [mailto:[email-masked]] On Behalf Of EXT Kent Watsen
Sent: Tuesday, December 15, 2015 10:35 PM
To: Benoit Claise <[email-masked]>; NETCONF <[email-masked]>
Subject: Re: [Netconf] draft-ietf-netconf-call-home: one week review period

Kent

Dear all,

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Tue, 15 Dec 2015 22:50:21 +0100

We could add a RFC editor note.

Regards, Benoit
> From: Netconf <[email-masked] 
> <mailto:[email-masked]>> on behalf of Benoit Claise 
> <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> latest version 15, addressing all the DISCUSSes, there were a series 
> of changes.

---

From: t.petch <[email-masked]>
Date: Wed, 16 Dec 2015 11:27:38 +0000

I missed that one in C.1 but I hope that the RFC Editor catches a few
more! For example,

"the attacker doesn't posses a valid key.  "

poss v.t. ' to mangle the language as a result of a review such as that
of
the IESG' :-)

Also

- the I-D uses a mixture of 'Issuer' and 'trust anchor' seemingly both
to refer to the top of the chain of certificates; what is the
significance of this?  For me, Trust Anchor is where it all starts,
where you must verify the chain of certificates to whereas Issuer is the
issuer of a certificate, any certificate, from end entity via
intermediate to trust anchor, but I realise that that opinions on this
vary.  RFC6125 uses trust anchor for the top of the chain while
RFC5280 uses Issuer for, well, the issuer of any certificate.

- likewise, the client security credential used for RESTCONF is a mix of
'shared secret', 'password' or 'shared key' - the last seems wrong to
me.  I note that the cited RFC, 7616 and 7617, use password.

- C.6 "Clients SHOULD
       ensure that the Issuer used to authenticate the presented
       certificate defines the namespace for the identifiers of
       interest.  "

I don't understand this.  If a certificate has a dNSName or iPAddress in
it, in what sense does the certificate define the namespace?

- S.5  I am surprised that the Security reviews did not mention the need
not to action messages prior to successful user authentication.  There
is a strong drive in the use of TLS by websites to eliminate round trips
so that user data is sent before a secure channel has been established,
with the data being resent or discarded if the setup of the secure
channel does not complete.  This requires applications to know what is
going on.  Likewise, where the user authentication is a separate
function, performed after the 'secure' channel has been set up, it may
be ok for the web user to send data and for the web server to act upon
it, albeit not in a way that could cause harm.  The use of these
protocols by NETCONF is rather different, acting on data from a
yet-to-be authenticated user could be unfortunate, and the server should
be cautious about accepting data until the secure channel really has
been set up.  I am thinking that before too long, we will have TLS
stacks that are optimised for fast web access but are a danger to
operational applications, and so might have added a phrase at the end of
S5 to the effect that any user data must be then discarded.  But if this
was not raised, then it is probably best left to linger a while longer.

- " For cases when the NETCONF/RESTCONF server presents an X.509
   certificate, NETCONF/RESTCONF clients should ensure that the Issuer
   certificate used for certificate path validation is unique to the
   manufacturer of the server.  That is, the certificate should not
   belong to a 3rd-party certificate authority that might issue
   intermediate certificates for more than one manufacturer.  "

This confuses me.  Issuer seems to be trust anchor from other uses of
the term so this seems to be saying that all servers of a given
manufacturer must have certificate chains leading back to the same trust
anchor and that that trust anchor must not issue certificates for any
other manufacturer - but then what is 'intermediate' doing in there?   I
would expect the number of intermediate certicates to range from zero to
n, but have otherwise no particular properties.

I note that the Normative reference to restconf means that this will not
advance for many months, but guess that that time is best spent in the
RFC-Editor queue.

Tom Petch

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "Benoit Claise" <[email-masked]>; "NETCONF" <[email-masked]>
Sent: Tuesday, December 15, 2015 9:34 PM

> From: Netconf
<[email-masked]<mailto:[email-masked]>> on behalf of
Benoit Claise <[email-masked]<mailto:[email-masked]>>
> To: "[email-masked]<mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]>>
> I propose a one week review for those
changes<https://www.ietf.org/rfcdiff?url1=draft-ietf-netconf-call-home-1
1&url2=draft-ietf-netconf-call-home-15>, before I sent this document to
the RFC-editor queue.

---

From: Kent Watsen <[email-masked]>
Date: Wed, 16 Dec 2015 18:59:11 +0000

Hi Tom,

Thanks for your review, while most of this the editor can catch, a couple issues you raised are a more involved (see below), thus I plan to post a -16 with these fixes, along with the fix for the issue that I found earlier.

>poss v.t. ' to mangle the language as a result of a review such as that

fixed!  (s/posses/possess/)

>RFC5280 uses Issuer for, well, the issuer of any certificate.

The draft originally had Trust Anchor everywhere, but then Joe Salowey (TLS co-chair) also said that a "Trust Anchor" typically refers to a self-signed cert (a root cert), and so I started writing “Issuer” in new text, but never updated the old text.   

Fixed!  (replaced “Trust Anchor” with “Issuer”, and removed capitalization on “issuer”)

>me.  I note that the cited RFC, 7616 and 7617, use password.

Fixed!  (replaced "shared key" with "shared secret (e.g., a password)”)

>it, in what sense does the certificate define the namespace?

I’m think that this sentence in C-6 should be removed, as the Security Considerations section says it better:

    For cases when the NETCONF/RESTCONF server presents an X.509
    certificate, NETCONF/RESTCONF clients should ensure that the
    issuer certificate used for certificate path validation is
    unique to the manufacturer of the server.  That is, the certificate
    should not belong to a 3rd-party certificate authority that
    might issue intermediate certificates for more than one manufacturer.

Both the sentence in C-6 sentence the the Security Considerations paragraph were added to address an item from Stephen Farrell.   You can see them both in one github commit here: https://github.com/netconf-wg/call-home/commit/1b9d54f5f4b441c8c79d65b038080b402e7e0ab4.

Do we need to get Stephen’s approval to remove the sentence in C-6 now?   (question for chairs or AD)

>was not raised, then it is probably best left to linger a while longer.

Agreed (no change)

>n, but have otherwise no particular properties.

Fixed!  (removed word “intermediate”)

>advance for many months, but guess that that time is best spent in the

True, but hopefully not for too many months!  ;)

>Tom Petch

Thanks again,
Kent

---

From: Benoit Claise <[email-masked]>
Date: Wed, 16 Dec 2015 20:44:16 +0100

Including Stephen,

Stephen, there is a question for you in there.
>> "the attacker doesn't posses a valid key."
>>
Yes.

Regards, Benoit

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Dec 2015 21:57:59 +0000

Hi Benoit.

First, thanks to Benoit and Kent for explaining this to me off-list.
(I needed the explanation;-)

The changes below seem fine to me, thanks for checking,
S.

On 16/12/15 19:44, Benoit Claise wrote:
>> Thanks for your review, while most of this the editor can catch, a
>> couple issues you raised are a more involved (see below), thus I plan
>> to post a -16 with these fixes, along with the fix for the issue that
>> I found earlier.
>>
>> Regarding your comments:
>>
>>
>>
>>
>>
>>
>>
>> The draft originally had Trust Anchor everywhere, but then Joe Salowey
>> (TLS co-chair) also said that a "Trust Anchor" typically refers to a
>> self-signed cert (a root cert), and so I started writing “Issuer” in
>> new text, but never updated the old text.
>>
>> Both the sentence in C-6 sentence the the Security Considerations
>> paragraph were added to address an item from Stephen Farrell.   You
>> can see them both in one github commit here:
>> https://github.com/netconf-wg/call-home/commit/1b9d54f5f4b441c8c79d65b038080b402e7e0ab4.
>>
>>
>>

---

From: t.petch <[email-masked]>
Date: Fri, 18 Dec 2015 17:30:50 +0000

Kent

[Keeping Stephen on the CC since this is another possible one word
change in the Security Considerations. ]

Yes, definitely better.  I still have one doubt, an ambiguity that I
think does make a material difference to certificate validation, now
that issuer is a generic term for the issuer of a certificate.

5.  Security Considerations
....                                            this RFC requires that
the
   NETCONF/RESTCONF client validate the server's SSH host key or
   certificate, by certificate path validation to a preconfigured issuer
   certificate, or by ..
[yes, that is clear]

...            NETCONF/RESTCONF clients should ensure that the issuer
   certificate used for certificate path validation is unique to the
   manufacturer of the server.
[ not so clear - should that be 'preconfigured issuer certificate'? -
'the certificate' implies to me a one and only whereas certificate path
validation potentially involves many certificates in a path and since we
are imposing a condition thereon, that makes a difference.  Does '
certificate should not belong to a 3rd-party certificate authority that
... ' apply to all certificates in the path validation or just to the
preconfigured issuer certificate?
I don't know but see it affecting an implementation and the security
implications thereof]

Tom Petch

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "Benoit Claise" <[email-masked]>; "Kent Watsen"
<[email-masked]>; "t.petch" <[email-masked]>; "NETCONF"
<[email-masked]>
Sent: Wednesday, December 16, 2015 9:57 PM
> >> I’m think that this sentence in C-6 should be removed, as the
Security
> >> Considerations section says it better:
> >>
https://github.com/netconf-wg/call-home/commit/1b9d54f5f4b441c8c79d65b03
8080b402e7e0ab4.
> >>>    certificate, NETCONF/RESTCONF clients should ensure that the
Issuer

---

From: Kent Watsen <[email-masked]>
Date: Fri, 18 Dec 2015 18:57:55 +0000

Hi Tom,

Thanks for sticking with this.

Okay, so responding from the bottom up.

1. I believe that it is okay for the clause "certificate should not belong to a 3rd-party certificate authority" to apply to just the preconfigured issuer certificate, as any intermediate CA certificates it may sign are going to be under its scope, and hence also not belong to a 3rd-party certificate authority.

2. Regarding adding the word “preconfigured” in the sentence "NETCONF/RESTCONF clients should ensure that the [preconfigured] issuer certificate used for certificate path validation is unique to the manufacturer of the server.”, I agree that it is a little more clear, since it uses the exact same adjectives, but I also believe that the existing sentence, as it stands, is technically correct/unambiguous.  Just the same, since we agree that its better, I’m to post a -17 with this one word change, which appears to me as a minor editorial fix.  That said, I’ll hold off for a couple days just in case anyone wants to voice an objection.

Thanks again,
Kent

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 22 Dec 2015 13:44:37 -0800

The one week review period for the above draft ends today. A -17 <https://tools.ietf.org/html/draft-ietf-netconf-call-home-17> version of the draft incorporates comments received during this review period. This document will be forwarded for RFC publication.

Thanks.

> On Dec 15, 2015, at 10:12 AM, Benoit Claise <[email-masked]> wrote:
> 
> Dear all,
> 
> I propose a one week review for those changes <https://www.ietf.org/rfcdiff?url1=draft-ietf-netconf-call-home-11&url2=draft-ietf-netconf-call-home-15>, before I sent this document to the RFC-editor queue.
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
[email-masked]

---

From: Benoit Claise <[email-masked]>
Date: Wed, 23 Dec 2015 10:32:03 +0100

On 12/22/2015 10:44 PM, Mahesh Jethanandani wrote:
> The one week review period for the above draft ends today. A -17 
> <https://tools.ietf.org/html/draft-ietf-netconf-call-home-17> version 
> of the draft incorporates comments received during this review period. 
> This document will be forwarded for RFC publication.
Now done.
Thanks all for your work on this one.

Regards, Benoit
>
> Thanks.
>
>
>> On Dec 15, 2015, at 10:12 AM, Benoit Claise <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Dear all,
>>
>> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
>
>
>