Re: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt

["Panos Kampanakis (pkampana)" <[e-mail]>]

Hi Esko,

Thank you again. Again a very elaborate review and found some good nits in the Delayed responses section. To make it easier I logged the issues and fixes here https://github.com/SanKumar2015/EST-coaps/issues/145 

The updated doc is here https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt and the diffs are here https://github.com/SanKumar2015/EST-coaps/commit/4ad5210faf624c67e1998da75ea051de616e91b1#diff-3a712edb43f6eace7fb1667328d65307  

Rgs
Panos

-----Original Message-----
From: Esko Dijk <[e-mail]> 
Sent: Tuesday, May 21, 2019 6:31 PM
To: Panos Kampanakis (pkampana) <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: RE: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt

Hello Panos,

For the draft text I have a couple of more review remarks:

* page 8 first bullet: a previously issues client certificate could also expire, in some cases even without the client knowing. If the client then performs simple re-enrollment -- using its previous operational cert as authentication, what would happen?  I would expect the server MAY also want to use this certificate to authenticate the client. Because the purpose of the client connecting again to the EST server is to do simple re-enrollment, to get a new certificate.   Suppose a case where the handshake to the EST server fails because the EST server rejects the expired operational cert:  what would the client do now? It could be a certificate_expired message.  RFC 7030 provides no guidance in this matter; would EST-coaps need to define this? E.g. client SHOULD retry using the bullet #2 certificate (e.g. IDevID)?

* page 8 middle: "CoAP and DTLS can provide proof-of-identity for EST-coaps clients and servers with simple PKI messages as described in Section 3.1 of [RFC5272] "
Looking up this section it says: "The Simple PKI Request MUST NOT be used if a proof-of-identity needs to be included."   This seems to say the opposite of the above text?  This requires at least some more explanation.

* page 8 middle: "Moreover, channel-binding information for linking proof-of-identity with connection-based proof-of-possession is OPTIONAL for EST-coaps"  -> is it OPTIONAL for client, server, or both? I would assume it is OPTIONAL for both. If the (light-weight) client does not implement it and if the server does mandate it, the client can not connect to that server if its policy is set to "linking POP/identity required".

* page 14 top bullet: "The CoAP Options used are .... " 
  -> the item Block could be expanded to "Block1, Block2" to capture the actual Option names.
  -> Location-Path is never used in any of the CoAP interactions defined; should be removed.

* Page 14 first 5.5 paragraph: "Similarly, 2.01, 2.02 or 2.04 MUST be used in response to EST POST requests"
  -> 2.01 Created is like HTTP 201, which is not used in EST - so can be removed here.
  -> 2.02 Deleted has no HTTP equivalent, so is not used in EST. It should be removed here.
  -> that leaves only 2.04 responses. However the text should say this is for successful (HTTP 200 or 202 in EST) responses , so suggestion is to change above sentence to: "Similarly, 2.04 MUST be used in a response to a successful EST POST request"

* page 14 bottom: "EST makes use of HTTP 204 and 404 responses when a resource is not  available for the client.  The equivalent CoAP codes to use in an EST-coaps responses are 2.04 and 4.04.  "
  -> CoAP 2.04 can only be used in responses to POST or PUT requests, not for GET responses.
  -> so in CoAP the server could either return 2.05 with empty payload (equivalent to HTTP 204), or return 4.04 (equivalent to HTTP 404)

* page 15 bottom: "The EST-coaps client and server MUST support Block2.  Block1 MUST be supported for EST-coaps enrollment requests that exceed the Path MTU."
  -> could be clarified better, I expect a EST-coaps server MUST support Block1 because that server doesn't know in advance how big the client's request payload is going to be and whether that client will use Block1.
  -> e.g. "The EST-coaps client and server MUST support Block2.  The EST-coaps server MUST support Block1. The EST-coaps client MUST support Block1 if it sends EST-coaps requests with an IP packet size that exceeds the Path MTU."

* page 16 example: the payloads are not indicating that each "{CSR req}" payload is different. I.e., a different block. It would be more clear if that is shown e.g. "{CSR 1}", "{CSR 2}", ... up to "{CSR N1+1}". The "req" string is not needed since the R in CSR already stands for request.

* page 17 example: see above payloads remark; and the following:
  --> what I find strange here is that a blockwise POST request ends with a 5.03 response, and then the same request after that gives a 2.01 response. In CoAP AFAIK, one request can never give 2 responses in sequence.
  --> once a response is delivered back to the client piggybacked on an ACK, the server closes the transaction normally and no further state for the transaction is kept.
  --> normally if a server sends 5.03 with Max-Age the client needs to send a new request i.e. retry with a new request after this waiting time.   That implies the client would need to resend the entire request: all blocks of it!
  --> I do realize that resending all blocks is very inefficient ; but at the same time the example also seems incompatible with CoAP specs.
  --> another question is why does the server use Block2 option in the 5.03 response that has no payload. In RFC 7959 Section 2.1, "the Block2 Option pertains to the response payload" and "payload-bearing responses". So it should be just left out in the response without payload I think.
  --> I understand this sequence of messages was tested using interops/code; was a specific CoAP library used that exhibits this behavior? I would be interested to understand better why this works.

Hope these comments can still be used for improvement of the spec. I will send further review comments in a next email: still need to write these down.

Best regards
Esko



-----Original Message-----
From: Panos Kampanakis (pkampana) <[e-mail]> 
Sent: Monday, May 20, 2019 17:31
To: Esko Dijk <[e-mail]>; [e-mail]
Subject: RE: [Ace] I-D Action: draft-ietf-ace-coap-est-11.txt

Thanks Esko. 

Addressed in https://github.com/SanKumar2015/EST-coaps/blob/84ce0c1d5e768d40e97184214bae404da21bd050/draft-ietf-ace-coap-est.xml Two comments: 

> page 11 bottom requirement: " The client SHOULD use resource discovery when he is unaware of the available  EST-coaps resources." - when an EST server is known, this requirement does not really apply since the server always supports .well-known EST resources.  So I read it as doing an RD discovery or multicast CoAP discovery if the client doesn't known the EST server address.  Hope this is clear enough in the text and intended?

There are optional resources like /att, /skg and /skc that the server does not have to support, so that is what this sentence was referring to. 

> page 11 bottom: " It is up to the implementation to choose its resource paths” -> seems not really the case, because the root resource structure is forced by the specification. It could have been designed as free choice (because it can be discovered anyway) but it is not.

The text says that the server MUST support the default /.well-known/est root resource and it SHOULD support resource discovery for non-default URIs (like /est or /est/ArbitraryLabel) or ports. In the latter case it is up to the server to decide the paths he makes its resources available at. That is what this sentence was referring to. But you are right; I realized that this sentence is redundant so I only kept "Throughout this document the example root resource of /est is used."

Will reupload the next iteration in a few days. 

Rgs,
Panos