Subject: [Netconf] Stephen Farrell's No Objection on draft-ietf-netconf-restconf-17: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 12 Oct 2016 17:33:17 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-netconf-restconf-17: No Objection

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/

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

- What about tls1.3 0RTT/replayable-data? There may be a case
to be made to mention this here and e.g. to say that only
idempotent requests (or none) are allowed use 0RTT early data.
Equally you could argue to not say anything since tls1.3 isn't
yet finished. I'd argue that saying something here is better
(and that saying to not use 0RTT at all is best) since
RESTCONF will use standard https libraries, which will at some
point soon support 0RTT and that might even make that happen
more easily than they ought. (This isn't a discuss as tls1.3
isn't yet done so I'd not feel right blocking on this basis,
but were tls1.3 done, which it will be soon I hope, this
would be a definite discuss as RESTCONF differs enough from
a browser for this to be a cause of possibly really bad
security problems.)

1.4: "Note that there are no interactions at all between the
NETCONF protocol and RESTCONF protocol.  It is possible that
locks are in use on a RESTCONF server, even though RESTCONF
cannot manipulate locks.  In such a case, the RESTCONF
protocol will not be granted write access to data resources
within a datastore." What you mean is clear, but the text is,
I think, self-contradictory - what is described is an
interaction between the two protocols. (And so is the fact
that access controls need to be commensurate between the two
protocols.) 

- section 2: would it be useful to add a reference to BCP195
and say that adhering to that is a good idea?  I think you
could maybe actually lose some (but not all) of the text here
via that single reference. (That might help a bit with
Alexey's discuss, not sure.)

- 2.5: "MUST use tls-cilent-auth or MUST use any HTTP
authentication scheme" is (as Kathleen noted) wishy washy.
And that leaves out html-form-based client auth methods too it
seems. I think you could word this better. (Not that that's
likely to affect the reality that clients here will just use
web engines so there's probably no point in expecting that
RESTCONF can use anything out of the ordinary.) The same
comment applies to section 12 where the same wishy-washy
statement occurs.

- 12: "There are many patterns of attack..." that screams
out for references, please add some to give the reader
a chance to understand if they don't already know.

---

From: Kent Watsen <[email-masked]>
Date: Thu, 13 Oct 2016 19:48:10 +0000

Hi Stephen,

Just picking out your comments that affect my sections:

> more easily than they ought. 

How about this in the Security Considerations section?

  Section 2.1 states “A RESTCONF server MUST support the TLS
  protocol [RFC5246]”.  This language leaves open the possibility
  that a RESTCONF server might also support future versions of the
  TLS protocol.   Of specific concern, TLS 1.3 [draft-ietf-tls-tls13]
  introduces support for 0-RTT handshakes that can lead to security
  issues for REST APIs, as described in the Appendix of the TLS 1.3
  RFC.  It is therefore RECOMMENDED that RESTCONF servers do not
  support 0-RTT at all (not even for idempotent requests) until an
  update to this RFC guides otherwise.

> Alexey's discuss, not sure.)

Currently section 2 has the sentence: “A RESTCONF server MUST 
support the TLS protocol [RFC5246].”   Would it be acceptable
to add to that sentence “, and SHOULD adhere to BCP 195.”? 

As for removing text after referencing BCP 195, I don’t see much
overlap.  For instance, BCP 195 has a whole section to recommend
TLS 1.2, but already RESTCONF is using TLS 1.2.  Please let me 
know if you had an idea for which text could be removed.

> comment applies to section 12 where the same wishy-washy

Weird, I searched my mail and I can’t find Kathleen calling 
out that “wishy washy” sentence.  Regardless, I looked at it
again and don’t see how to word it better.  FWIW, the current
wording is the result of WG wordsmithing; the sentence use
to have MAY instead of MUST, but folks felt that it wasn’t
accurate enough.  Do you have a suggestion for wording it better?

As for leaving out html-form based auth, this is fine, RESTCONF
doesn’t support forms.

Thanks,
Kent

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 14 Oct 2016 11:42:09 +0100

Hi Kent,

>   update to this RFC guides otherwise.

I like that.

> to add to that sentence “, and SHOULD adhere to BCP 195.”? 

Again, that's an improvement I think.

> know if you had an idea for which text could be removed.

Haven't had time to do that sorry and won't have today so
you're probably right to not delete anything at this point.

> out that “wishy washy” sentence.  

I meant Kathleen's ballot comment [1]

She didn't say "wishy washy" though:-)

   [1]
https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ballot/#kathleen-moriarty

> Regardless, I looked at it

So the current (-17) text is:

   To authenticate a client, a RESTCONF server MUST use TLS based client
   certificates (Section 7.4.6 of [RFC5246]), or MUST use any HTTP
   authentication scheme defined in the HTTP Authentication Scheme
   Registry (Section 5.1 in [RFC7235]).

The construct "MUST use <good-thing> or MUST use <bad-thing>"
is what I meant by wishy washy since that really means "use
<good-thing> or <bad-thing>" doesn't it?

If it was acceptable then I'd go for:

   To authenticate a client, a RESTCONF server SHOULD require TLS
   client authentication (Section 7.4.6 of [RFC5246]).

   If TLS client authentication is not feasible (e.g. because
   one cannot build the required PKI for clients) then HTTP
   authentication can be used. In the latter case one of the HTTP
   authentication scheme defined in the HTTP Authentication Scheme
   Registry (Section 5.1 in [RFC7235]) MUST be used.

> As for leaving out html-form based auth, this is fine, RESTCONF

Ack.

Thanks,
S.

---

From: Kent Watsen <[email-masked]>
Date: Fri, 14 Oct 2016 18:30:52 +0000

Hi Stephen,

> She didn't say "wishy washy" though:-)

I see, this is where she and I settled on this text:

   Client
   authentication MUST be implemented using client certificates or MUST
   be implemented using an HTTP authentication scheme.  The strength of
   these methods vary greatly.  For example, use of a client certificate
   is RECOMMENDED, while HTTP Basic authentication [RFC7617] is
   NOT RECOMMENDED.

>   Registry (Section 5.1 in [RFC7235]) MUST be used.

To be honest, I think your text states the recommendation more clearly.  I think we should use your text for this section in the draft, and then add to the Security Considerations section something like the following to capture Kathleen’s comment:

  Section 2.5 recommends TLS client certificate based authentication,
  but allows the use of any authentication scheme defined in the HTTP
  Authentication Scheme Registry.  Implementations need to be aware
  that the strength of these methods vary greatly, and that some may be
  considered experimental.  Selection of any of these schemes SHOULD
  be performed after reading the Security Considerations section of 
  the RFC associated with the scheme’s registry entry.

What do you think?

Actually, I’d like to modify your text above just a little to:

   To authenticate a client, a RESTCONF server SHOULD require TLS
   client certificate based authentication (Section 7.4.6 of [RFC5246]).
   If certificate based authentication is not feasible (e.g. because
   one cannot build the required PKI for clients) then an HTTP
   authentication MAY be used. In the latter case one of the HTTP
   authentication schemes defined in the HTTP Authentication Scheme
   Registry (Section 5.1 in [RFC7235]) MUST be used.

Okay?

Thanks,
Kent

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 14 Oct 2016 20:51:53 +0100

Hi Kent,

That all works for me,

Cheers,
S.