Subject: [Netconf] Alexey Melnikov's Discuss on draft-ietf-netconf-restconf-17: (with DISCUSS and COMMENT)

From: "Alexey Melnikov" <[email-masked]>
Date: Wed, 12 Oct 2016 11:26:00 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-netconf-restconf-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for a well written document. I have a few minor points which I
would like to discuss before recommending approval of this document:

1) In 2.4: TLS server identity verification using RFC 6125 is
underspecified. Please provide all details as described in Section 3 of
RFC 6125, in particular, please specify which of CN-ID, DNS-ID, SRV-ID,
URI-ID are allowed/required and whether wildcards are allowed in them.

2) In 3.5.3.1:

api-path is using "|" instead of "/" for alternatives.

The "*" must be before a rule, not after it.

It looks like the ABNF was not validated with a tool, so there might be
other errors in it.

3) In 4.6: 
... server MUST support the PATCH method. ... . It is optional to
implement by the server.

 - These statements seem to be in conflict.

4) In 5.2:

The server is only required to implement one of XML / JSON. Does this
mean that a compliant client need to support both in order to achieve
interoperability? The document doesn't say that.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In 1.4: is it possible to expose separate :candidate, :startup and
:writeable-running over RESTCONF? Section 1.4 seem to imply that only one
can be used.

In 3.5.3: you are listing "reserved" URI characters, you should point to
RFC 3986 as the authoritative reference.

In 4.4.2: can 404 be returned instead of 403?

On page 45 (in the middle of the page): some references to RFCs and
sections look incorrect (wrong formatting).

In 4.5: it would be good to see an example creating/replacing the whole
datastore.

At the bottom of page 47: I see an extra dot in the middle of a
sentence.

In 4.8.4: I think XPath should be a normative reference there.

In 5.5: what is the reason for Cache-Control being a SHOULD and not a
MUST?

In 11.3.1:

Subtype must include "+xml" in its value.

Fragment identifier: can you just say "same as for application/xml"?

File extension: don't you want to define a new one? (.xml is fine as a
fallback)

11.3.2:

The same comment about file extensions as above.

---

From: Kent Watsen <[email-masked]>
Date: Wed, 12 Oct 2016 20:50:57 +0000

Hi Alexey,

Regarding your DISCUSS #1:
 
  In 2.4: TLS server identity verification using RFC 6125 is
  underspecified. Please provide all details as described in Section 3 of
  RFC 6125, in particular, please specify which of CN-ID, DNS-ID, SRV-ID,
  URI-ID are allowed/required and whether wildcards are allowed in them.

RESTCONF is based on HTTPS [RFC2818]; it is expected that RESTCONF servers will follow general HTTPS guidelines for their server certificates.  Section 2.4 used to be longer, but the WG felt that repeating text from other drafts might lead to ambiguity and/or conflict, as so we trimmed it down to what it is now.

Additionally, I’m thinking that Section 3 of RFC 6125 regards application instances more
so than generic TLS-based protocols.  Specifically, while the RESTCONF *protocol* may not be sensitive to how a given RESTCONF server is discovered, a given RESTCONF server *does care*, as it would need to ensure that its server cert is filled in sufficiently for the client to validate it (i.e., with matching reference identifiers).

Is this response sufficient to address this DISCUSS?

Thanks,
Kent

---

From: "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>
Date: Thu, 13 Oct 2016 12:49:25 +0000

Hi Alexey,

concerning:
> Discuss 4) In 5.2:

Section 5.2 says:
==   Request input content encoding format is identified with the Content-
==   Type header field.  This field MUST be present if a message-body is
==   sent by the client.
==
==   The server MUST support the "Accept" header field and "406 Not
==   Acceptable" status-line, as defined in [RFC7231].  The response
==   output content encoding formats that the client will accept are
==   identified with the Accept header field in the request. 

We think that the client behavior is defined via the Accept header.
I wonder whether this is sufficient from your pov. If not could you please 
give us a hint what should be mentioned additionally.

There is another thread for Discuss 1) 
Discuss 2) will be fixed as requested.
Discuss 3) is a bug and will be fixed as requested.

Thanks, 
Mehmet 

-----Original Message-----
From: Alexey Melnikov [mailto:[email-masked]] 
Sent: Wednesday, October 12, 2016 8:26 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; Ersue, Mehmet (Nokia - DE/Munich) <[email-masked]>; [email-masked]
Subject: Alexey Melnikov's Discuss on draft-ietf-netconf-restconf-17: (with DISCUSS and COMMENT)

2) In 3.5.3.1:

3) In 4.6: 

4) In 5.2:

In 11.3.1:

11.3.2:

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 13 Oct 2016 14:53:52 +0200 (CEST)

Hi,

> https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/

[...]

> It looks like the ABNF was not validated with a tool, so there might be

Correct :(  I have now fixed the bugs in these rules (there were
other bugs as well...), and I have added tool-validation of the grammar.

Thanks for spotting this!

/martin

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 13 Oct 2016 14:19:01 +0100

Hi Mehmet,

On Thu, Oct 13, 2016, at 01:49 PM, Ersue, Mehmet (Nokia - DE/Munich)
> give us a hint what should be mentioned additionally.

My concern is that you seem to be requiring clients to support 2
encodings, because servers are not required to support both of them.
This seems like a high bar for implementations. Was this discussed in
the WG?

> There is another thread for Discuss 1) 

Yes, I will reply to that separately.

> Cc: [email-masked]; [email-masked]; Ersue,
> Mehmet (Nokia - DE/Munich) <[email-masked]>; [email-masked]

---

From: Kent Watsen <[email-masked]>
Date: Thu, 13 Oct 2016 13:30:21 +0000

Hi Alexey,

Yes, the WG discussed this extensively, about a year ago.  At first we had XML encoding as mandatory to implement, but there were many who wanted their RESTCONF servers to only have to support JSON.  This was/is especially concerning for low-end servers, where resources are tight.

I’d point you to the thread, but I have to jump into a meeting tight now...

Thanks,
Kent

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 13 Oct 2016 14:34:29 +0100

Hi Kent,

On Thu, Oct 13, 2016, at 02:30 PM, Kent Watsen wrote:
> Yes, the WG discussed this extensively, about a year ago.  At first we
> had XML encoding as mandatory to implement, but there were many who
> wanted their RESTCONF servers to only have to support JSON.  This was/is
> especially concerning for low-end servers, where resources are tight.
> 
> 

Ok, I trust that this discussion has happened. I would like a sentence
to be added that says that for interoperability clients need to support
both encodings, unless they are working against a specific
implementation. That would address this point.

Thank you,
Alexey

---

From: Benoit Claise <[email-masked]>
Date: Thu, 13 Oct 2016 15:42:39 +0200

On 10/13/2016 3:34 PM, Alexey Melnikov wrote:
> Ok, I trust that this discussion has happened.
Yes. See 
https://mailarchive.ietf.org/arch/msg/netconf/YSEbLd-nnI0dlkeiIeGW-z6JqDg 
and search for "Discovery of the Encoding Format WAS:FW: Opinion poll 
for the RESTCONF encoding" on the NETCONF mailing list
> I would like a sentence
That seems reasonable.

Regards, B.
> .

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 13 Oct 2016 14:57:07 +0100

Hi Kent,

On Wed, Oct 12, 2016, at 09:50 PM, Kent Watsen wrote:
> RESTCONF is based on HTTPS [RFC2818]; it is expected that RESTCONF
> servers will follow general HTTPS guidelines for their server
> certificates.  Section 2.4 used to be longer, but the WG felt that
> repeating text from other drafts might lead to ambiguity and/or conflict,
> as so we trimmed it down to what it is now.

It is a shame that RFC 2818 was not updated to use RFC 6125. However
this is not your problem.

So basically you have 2 choices: you either reference RFC 2818 (and
don't reference RFC 6125 at all) or you add more information about how
to use RFC 6125.

> so than generic TLS-based protocols. 

It was intended for protocols.

> Specifically, while the RESTCONF
> *protocol* may not be sensitive to how a given RESTCONF server is
> discovered, a given RESTCONF server *does care*, as it would need to
> ensure that its server cert is filled in sufficiently for the client to
> validate it (i.e., with matching reference identifiers).
>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 13 Oct 2016 16:00:17 +0000

Hi Alexey,

>this is not your problem.

FWIW, RESTCONF actually references RFC 7230, which references RFC 2818, but your point is still valid.

>don't reference RFC 6125 at all) or you add more information about how

Regarding choice #1: Scanning the RESTCONF draft, the only reference to RFC 6125 is happening in this section (Section 2.4), so switching to RFC 2818 would be fairly easy.  Presumably this section would be rewritten to point to RFC 2818, Section 3.1 instead.

Regarding choice #2: would adding to the beginning of this section (Section 2.4) something like the following be okay?  “RESTCONF servers using DevID certificates MUST configure their certificates according to IEEE-802.1AR-2009, otherwise RESTCONF servers SHOULD configure their certificates according to the guidelines in Section 3 of RFC 6125.”

Kent

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 15 Oct 2016 23:22:31 +0100

Hi Kent,

> On 13 Oct 2016, at 17:00, Kent Watsen <[email-masked]> wrote:
> 
> Hi Alexey,
> 

Exactly, it affects all protocols using HTTPS.
> Regarding choice #1: Scanning the RESTCONF draft, the only reference to RFC 6125 is happening in this section (Section 2.4), so switching to RFC 2818 would be fairly easy.  Presumably this section…

Yes (I didn't check the section).

> Regarding choice #2: would adding to the beginning of this section (Section 2.4) something like the following be okay?  “RESTCONF servers using DevID certificates MUST configure their certificates…

This, plus you still need to say which of CN-ID, DNS-ID, SRV-ID and/or URI-ID are to be used and whether wildcards are allowed in CN-IDs and DNS-IDs (if used).

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Oct 2016 09:25:35 +0100

Hi Alexey,

Kent was asking me about this offlist, and I'm also a bit
puzzled now...

On 13/10/16 17:00, Kent Watsen wrote:
>> So basically you have 2 choices: you either reference RFC 2818
>> (and don't reference RFC 6125 at all) or you add more information
>> about how to use RFC 6125.

Isn't that a false dichotomy? At least if by "add more"
you mean, "you must add all of <these> things"? But see
below...

> 
> Regarding choice #1: Scanning the RESTCONF draft, the only reference
> to RFC 6125 is happening in this section (Section 2.4), so switching
> to RFC 2818 would be fairly easy.  Presumably this section would be
> rewritten to point to RFC 2818, Section 3.1 instead.
> 
> Regarding choice #2: would adding to the beginning of this section
> (Section 2.4) something like the following be okay?  “RESTCONF
> servers using DevID certificates MUST configure their certificates
> according to IEEE-802.1AR-2009, otherwise RESTCONF servers SHOULD
> configure their certificates according to the guidelines in Section 3
> of RFC 6125.”

Actually, I'd have thought that 6125, appendix B would help
here - why wouldn't the same as is used for netconf [1]
work here? If that works, I'd just refer to that and we
should be fine. (And it'd be nice if we get the benefit
that the same server cert can work for both too I guess.)

Cheers,
S.

[1] https://tools.ietf.org/html/rfc6125#appendix-B.7

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 17 Oct 2016 10:02:17 +0100

Hi Stephen,

> On 17 Oct 2016, at 09:25, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi Alexey,
> 
> you mean, "you must add all of <these> things"?

No. Just saying "Use RFC 6125" is incorrect, because it provides a template, not a fully specified set of rules. So any document referencing it need to prescribe which identity types are used (CN-ID, DNS-ID, etc) and whether wild cards are allowed in any of them.

I didn't imply that a spec needs to support all identity types. Most likely NETCONF should support DNS-ID. Possibly CN-ID. SRV-ID is only used if something like DNS SRV is used for server discovery.

> But see

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Oct 2016 10:05:49 +0100

On 17/10/16 10:02, Alexey Melnikov wrote:
>> Kent was asking me about this offlist, and I'm also a bit puzzled
>> now...
>> 
>>>> (and don't reference RFC 6125 at all) or you add more
>>>> information about how to use RFC 6125.
>> 
>> Isn't that a false dichotomy? At least if by "add more" you mean,
>> "you must add all of <these> things"?
> 
> No. Just saying "Use RFC 6125" is incorrect, because it provides a
> template, not a fully specified set of rules. So any document
> referencing it need to prescribe which identity types are used
> (CN-ID, DNS-ID, etc) and whether wild cards are allowed in any of
> them.
> 
> I didn't imply that a spec needs to support all identity types. Most
> likely NETCONF should support DNS-ID. Possibly CN-ID. SRV-ID is only
> used if something like DNS SRV is used for server discovery.

Right. DNS-ID is what's needed with CN only needed if there are
legacy deployment issues. Those used be more important than now
though.

Anyway, what's wrong with just saying "same as 6125, B.7"? (I.e.
[1] below.)

S.

> 
>> But see below...
>> 
>>> 
>>> Regarding choice #1: Scanning the RESTCONF draft, the only
>>> reference to RFC 6125 is happening in this section (Section 2.4),
>>> so switching to RFC 2818 would be fairly easy.  Presumably this
>>> section would be rewritten to point to RFC 2818, Section 3.1
>>> instead.
>>> 
>>> Regarding choice #2: would adding to the beginning of this
>>> section (Section 2.4) something like the following be okay?
>>> “RESTCONF servers using DevID certificates MUST configure their
>>> certificates according to IEEE-802.1AR-2009, otherwise RESTCONF
>>> servers SHOULD configure their certificates according to the
>>> guidelines in Section 3 of RFC 6125.”
>> 
>> Actually, I'd have thought that 6125, appendix B would help here -
>> why wouldn't the same as is used for netconf [1] work here? If that
>> works, I'd just refer to that and we should be fine. (And it'd be
>> nice if we get the benefit that the same server cert can work for
>> both too I guess.)
>> 
>> Cheers, S.
>>

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 17 Oct 2016 10:12:16 +0100

> On 17 Oct 2016, at 10:02, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Stephen,
> 
>> should be fine.

The text in B.7 is what was used before RFC 6125. So just referencing it is incorrect.

I think the text in B.7 basically says:

DNS-ID type is used for matching.
CN-ID type might be used.
Wildcards are allowed in both.
URI-ID and SRV-ID are not used.

>> (And it'd be nice if we get the benefit

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Oct 2016 10:11:27 +0100

> The text in B.7 is what was used before RFC 6125. So just referencing

I don't get that at all. Because...

> URI-ID and SRV-ID are not used.

I'd bet the above is what's still wanted here, isn't it?
If so, why would we care about how that text is pointed
at?

Or are there additional things do you think actually need
to be stated to get TLS interop for this application? If
so, what? (Sorry, I'm not seeing it.)

S.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 17 Oct 2016 13:06:12 +0100

Hi Stephen,

> I'd bet the above is what's still wanted here, isn't it?

Yes. My text above, not what in B.7 :-).

> If so, why would we care about how that text is pointed

Because B.7 is extracts from RFCs that were used to motivate creation of
RFC 6125. It is using old, incorrect language that should not be used.

> Email had 1 attachment:
> + smime.p7s
>   5k (application/pkcs7-signature)

---

From: Kent Watsen <[email-masked]>
Date: Mon, 17 Oct 2016 17:56:21 +0000

Thanks Stephen for helping!

Hi Alexey, I think that I’ll go the RFC 2818 route.  Following is my proposed text.  Please suggest any changes you think would improve it!

OLD:

   2.4.  Authenticated Server Identity

      The RESTCONF client MUST check the identity of the server according
      to Section 6 of [RFC6125], including processing the outcome as
      described in Section 6.6 of [RFC6125].

NEW:

   2.4.  Authenticated Server Identity

      The RESTCONF client MUST check the identity of the server according
      to Section 3.1 of [RFC2818].

Does this update clear your DISCUSS item #1?

Thanks,
Kent

On 10/17/16, 8:06 AM, "Alexey Melnikov" <[email-masked]> wrote:

Hi Stephen,

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 17 Oct 2016 19:46:20 +0100

> On 17 Oct 2016, at 18:56, Kent Watsen <[email-masked]> wrote:
> 

Yes.

---

From: t.petch <[email-masked]>
Date: Wed, 19 Oct 2016 10:51:57 +0100

----- Original Message -----
From: "Alexey Melnikov" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Sent: Monday, October 17, 2016 10:02 AM

template, not a fully specified set of rules. So any document
referencing it need to prescribe which identity types are used (CN-ID,
DNS-ID, etc) and whether wild cards are allowed in any of them.

Alexey

I realise that this has now been resolved by eliminating all reference
to RFC6125 but ...

When I look at RFC7589, all I see is

'   The NETCONF client MUST check the identity of the server according
to
   Section 6 of [RFC6125]. '

Admittedly, this was June 2015 and so a long time ago in security terms
but I am still surprised at the present discussion about how to verify
server identity!

Tom Petch

> >> Regarding choice #1: Scanning the RESTCONF draft, the only
reference

> >> (Section 2.4) something like the following be okay?  "RESTCONF
> >> of RFC 6125."
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 Oct 2016 10:58:30 +0100

Hi Tom,

> but I am still surprised at the present discussion about how to verify

I was not on IESG at the time. So arguably this RFC is also slightly
underspecified.

If it helps, I can write down specific text to be added.

---

From: t.petch <[email-masked]>
Date: Wed, 19 Oct 2016 12:23:55 +0100

----- Original Message -----
From: "Alexey Melnikov" <[email-masked]>
Sent: Wednesday, October 19, 2016 10:58 AM

> > > >>> (and don't reference RFC 6125 at all) or you add more
information
> > referencing it need to prescribe which identity types are used
(CN-ID,
> If it helps, I can write down specific text to be added.

Alexey,

[Trimming the distribution since this is no longer about the DISCUSS]

No, leave it for now.

I was involved in this part of the text for both this I-D, and for
RFC7589, and earlier ones, and have commented to one of your
predecessors how I never know what to expect from a security review
(even when it is the same person as before) so your DISCUSS was no
surprise.  I will learn from it ready for the next time:-)

Tom Petch

> > > >> Regarding choice #2: would adding to the beginning of this
section
> > > >> configure their certificates according to the guidelines in
Section
> > 3

---

From: Kent Watsen <[email-masked]>
Date: Wed, 19 Oct 2016 12:31:20 +0000

> > '   The NETCONF client MUST check the identity of the server
> >     according to Section 6 of [RFC6125]. '

Thanks Tom, I was going to raise this inconsistency as well.

> If it helps, I can write down specific text to be added.

Alexey, thanks for the offer, but we’re good for now.

Kent