Re: [Ace] WGLC for draft-ietf-ace-coap-est

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

Hi Klaus,

Thanks for the thorough review. 

All your issues identified are tracked here https://github.com/SanKumar2015/EST-coaps/issues?utf8=%E2%9C%93&q=is%3Aissue+%22Klaus+WGLC%22 . We tried to address all of them. The fixes we are putting in are spelled out in the github issues themselves. The actual latest version of the draft is https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-coap-est.txt 

After proof reading the draft one more time we will upload early next week. 

Below I am answering some of the questions you asked in your review. 

> 4. -- Is this section about the generated certificates or the DTLS connection between the client and the server? If the latter, this section is weird, because RFC 7252 already does define MTI cipher suites and extensions, and I see no reason why an application layered on top of CoAP needs to restate all of that.

This section describes how the (D)TLS profile defined in RFC7925 is used by EST-coaps. It was asked by the original ACE co-chair to show conformance with ACE profiles.  It touches on the client server authentication, the tunnel ciphersuites. It explains how the EST-coaps data exchange is secured thereby preventing eavesdropping, tampering, and message forgery. We wanted to spell out for implementers which parts of RFC7925 they should take into consideration instead of just pointing them to RFC7925 or RFC7252 etc. 

> 4. "The authentication of the EST-coaps client MUST be with a client certificate in the DTLS handshake." -- Why? Why can't a client communicate with a server using any other secure mechanism with client authentication? Or is this just the MTI mechansim?

The issue is that EST mandates HTTP Basic or Digest Auth and/or client cert auth. HTTP Auth is not defined for COAP application as far as we know. So, for EST-coaps, the only viable authentication method is mutual cert auth. Other client auth methods could be defined, but are outside the scope of this draft. 
 
> 5.1. "Arbitrary Labels are usually defined and used by EST CAs in order to route client requests to the appropriate certificate profile." -- I assume that a client needs to construct URIs from the well-known path "/.well-known/est", the Arbitrary Label and one of the suffixes. How does a client determine which Arbitrary Label to use?

That is configured on the client out of band depending on the CA that generates the certs. It is outside the scope of EST or EST-coaps. 

> 5.1. "The EST-coaps server URIs, obtained through discovery of the EST-coaps root resource(s) as shown below, are of the form:" -- If a client discovers the URIs from "/.well-known/core" (annotated with "ace.est.crts", "ace.est.sen", etc.), is this table 1 still needed? If not, I would recommend that only the 'rt'  values are standardized ("ace.est.crts", "ace.est.sen", etc.) and all paths are left to the implementation, in accordance with BCP 190.

We intend to require /.well-known URIs so that resource discovery is not mandatory for pre-configured client deployments. Discovery is optional when non-default URIs are needed to save URI space. Feel free to check the text in https://github.com/SanKumar2015/EST-coaps/issues/123 where I edited the resource discovery text to make it clearer. 

> 5.1. "Discoverable port numbers MAY be returned in the <href> of the payload [I-D.ietf-core-resource-directory]." -- What does this mean?
> And what does Resource Directory have to do with EST?

We needed a way to be able tell the client that the resource is hosted on another port but the reference to  I-D.ietf-core-resource-directory is removed after Jim last WGLC We no longer use anchors, just an href in the payload. Check out https://github.com/SanKumar2015/EST-coaps/issues/136  

> 5.2. "Table 2 specifies the mandatory-to-implement or optional implementation of the est-coaps functions." -- How does a client discover which functions are implemented?

Client pre-configuration or optionally resource discovery. We added a reference to the discovery section. 

> 5.3. "Content-Format TBD287 can be used in place of 281" -- It's a bit difficult to see what TBD287 and 281 mean without scrolling all the way down and scrolling back up. Maybe include the table here to make the section easier to read?

I don't think that is necessary as we are stating that TBD287 and 281 "to carry a single certificate instead of a PKCS#7 container in a /crts, /sen, /sren or /skg response ". Also there is a reference to the IANA section in the paragraph above. 

> 5.7. "After a delay of Max-Age, the client SHOULD resend the identical CSR to the server." -- Just for my understanding: Does the submission of a specific CSR always lead to the same output, or can it happen (e.g., if the client submits an identical CSR weeks or months later) that the client would get a different output?

Submitting the same CSR will likely give the client a different output. The reason is that the server cert profile may have changed, but more importantly the issued certificate will have a different lifetime and thus signature value. 

> 5.7. "... or the client abandons for other reasons." -- Does the client need to signal in some way when it wants to abandon?

When the server asks the client to come back in x amount of time, it does not keep state of the client and thus will not care if he returns or not. So, we don't need to require the client to signal that he is giving up. 

> 5.8. "containing a CBOR array with four items Section 5.3" -- Do the two representations (each consisting of two CBOR array items) have to be in a particular order or can they appear in any order?

Any order is fine, since the you can tell what format each representation carries. 

> 6. "In a constrained CoAP environment, endpoints can't always afford to establish a DTLS connection for every EST transaction." -- I'm not aware of any requirement that says CoAP clients must establish a new DTLS connection for every request...

EST mandates using a new truststore after a cacerts request which most usually means a new TLS connection. We can't always require the client to do that in a constrained environment and thus this text. 

> I didn't review the appendices.

Pity, we are sure you could still uncover nits in there. 

Rgs,
Panos



-----Original Message-----
From: Ace <[e-mail]> On Behalf Of Klaus Hartke
Sent: Tuesday, February 12, 2019 12:38 PM
To: Jim Schaad <[e-mail]>
Cc: [e-mail]
Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est

Jim Schaad wrote:
> The chairs believe that the EST over CoAP draft is nearing the point 
> it should be sent to the IESG for publication.  We are therefore going 
> to have a Working Group Last Call on this document.  WGLC will until 
> 29th of this month.  Please review the document and send comments both 
> positive and negative to the list about its state.

I've performed a quick review of draft-ietf-ace-coap-est-08. Sorry for being late to the party.

2. "Therefore, this specification utilizes DTLS [RFC6347], CoAP [RFC7252] and UDP instead of TLS [RFC8446], HTTP [RFC7230] and TCP."
-- Is there a technical reason why EST could not be done over CoAP over TCP, TLS, WebSockets, or SMS?

I understand that it was fashionable at some point to fork a protocol like HTTP, layer some stuff on top of it and call it a new protocol.
However, I would strongly recommend that EST-coaps is presented as an application that is strictly layered on top of CoAP and doesn't define its own custom protocol stack.

4. -- Is this section about the generated certificates or the DTLS connection between the client and the server? If the latter, this section is weird, because RFC 7252 already does define MTI cipher suites and extensions, and I see no reason why an application layered on top of CoAP needs to restate all of that.

4. "The authentication of the EST-coaps client MUST be with a client certificate in the DTLS handshake." -- Why? Why can't a client communicate with a server using any other secure mechanism with client authentication? Or is this just the MTI mechansim?

5.1. The use of the well-known path "/.well-known/est" seems to follow the letter of BCP 190 but not the spirit. I don't see any reason why a well-known path is needed here. In fact, as the section emphasizes, short paths are important and an implementation will there likely want to do the "/.well-known/core"-based discovery of URIs. I would recommend that the entire use of "/.well-known/est" is dropped.

5.1. "Arbitrary Labels are usually defined and used by EST CAs in order to route client requests to the appropriate certificate profile." -- I assume that a client needs to construct URIs from the well-known path "/.well-known/est", the Arbitrary Label and one of the suffixes. How does a client determine which Arbitrary Label to use?

5.1. "The EST-coaps server URIs, obtained through discovery of the EST-coaps root resource(s) as shown below, are of the form:" -- If a client discovers the URIs from "/.well-known/core" (annotated with "ace.est.crts", "ace.est.sen", etc.), is this table 1 still needed? If not, I would recommend that only the 'rt'  values are standardized ("ace.est.crts", "ace.est.sen", etc.) and all paths are left to the implementation, in accordance with BCP 190.

5.1. "Clients and servers MUST support the short resource URIs. The corresponding longer URIs from [RFC7030] MAY be supported." -- Does this provide any benefit or is it just to annoy implementers? Like, we can have short paths, we can have long paths, we cannot decide, so let's have ALL OF THEM!

5.1. "In the context of CoAP, the presence and location of (path to) the management data are discovered by sending a GET request to "/.well-known/core" including a resource type (RT) parameter with the value "ace.est" -- I understand that EST defines the operations on the resources labeled with annotated with "ace.est.crts", "ace.est.sen", etc. but I don't understand what I can do with a resource that is annotated with "ace.est".

5.1. "The first line of the discovery response above MUST be included.
The five consecutive lines after the first MAY be included." -- When would I include what?

5.1. "The return of the content types allows the client to choose the most appropriate one." -- Does the example actually match what a server returns? E.g., does ct="62 280 284 281 TBD287" mean that a server actually returns a TBD287 representation or would it always be a 62 (multipart) representation that happens to contain a TBD287 representation?

5.1. "Port numbers, not returned in the example, are assumed to be the default numbers 5683 and 5684 for CoAP and CoAPS respectively" -- No need to make any assumptions. This is exactly what RFC 7252 specifies.
Please don't make any normative statements that just repeat (or
contradict) what RFC 7252 says.

5.1. "Discoverable port numbers MAY be returned in the <href> of the payload [I-D.ietf-core-resource-directory]." -- What does this mean?
And what does Resource Directory have to do with EST?

5.1. " The server MUST support the default /.well-known/est server root resource and port 5684." -- As said above, I would drop this entirely.

5.1. "Resource discovery is necessary when the IP address of the server is unknown to the client." -- Assuming that "resource directory" refers to "/.well-known/core"-based discovery of URIs, then this is wrong. If the IP address of a server is not known, then a client cannot retrieve the "/.well-known/core" of that server.

5.2. "Table 2 specifies the mandatory-to-implement or optional implementation of the est-coaps functions." -- How does a client discover which functions are implemented?

5.3. "Content-Format TBD287 can be used in place of 281" -- It's a bit difficult to see what TBD287 and 281 mean without scrolling all the way down and scrolling back up. Maybe include the table here to make the section easier to read?

5.3. "If an Accept Option is not included in the request, the client is not expressing any preference and the server SHOULD choose format 281.  If the preferred Content-Format cannot be returned, the server MUST send a 4.06 (Not Acceptable) response, unless another error code takes precedence for the response [RFC7252]." -- Please don't make any normative statements that repeat (or contradict) what RFC 7252 says.

5.3. "*application/multipart-core*" -- Formatting missing?

5.3. "The collection is encoded as a CBOR array [RFC7049] with an even number of elements. ..." -- This is already described in [I-D.ietf-core-multipart-ct]. Is there any reason why the text needs to be duplicated?

5.4. "All EST-coaps messages expect a response from the server, thus the client MUST send the requests over confirmable CON CoAP messages."
-- The use of confirmable messages for requests is completely unrelated to whether a response is expected or not. Also, it is entirely inappropriate for an application layered on top of CoAP to mandate the message type.

5.4. "The Ver, TKL, Token, and Message ID values of the CoAP header are not affected by EST." -- And it would be entirely inappropriate if they were. So I'm not sure what to do with this information.

5.4. "The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content-Format, Accept and Location-Path." -- Of course, a server must be prepared to receive requests that include other kinds of options (such as "ETag" or "If-Match") and handle these in accordance to RFC 7252.

5.4. "The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content-Format, Accept and Location-Path." -- The Block options seem to be missing.

5.4. "The Uri-Host and Uri-Port Options are optional." -- No, these options are not optional. They just can be encoded very efficiently (in 0 bytes) if they happen to have their default value.

5.4. "They are usually omitted as the DTLS destination and port are sufficient." -- No. The default values of the options are the IP destination address and UDP port, respectively (in CoAP-over-UDP).

5.4. "Alternatively, if a UDP port to a server is blocked, someone could send the DTLS packets to a known open port on the server and use the Uri-Port to convey the intended port he is attempting to reach."
-- Where is that coming from? Sounds extremely weird.

5.5. "Response code HTTP 202 Retry-After that existed in EST" -- HTTP doesn't have response codes. And there is no status code named "Retry-After" in HTTP.

5.5. "Moreover, if the Content-Format requested in the client Accept Option, is not supported the server MUST return a 4.06 (Not Acceptable), unless another error code takes precedence for the response." -- Please don't make any normative statements that repeat (or contradict) what RFC 7252 says.

5.7. "In particular, a slow server can respond to an EST-coaps enrollment request with an empty ACK with code 0.00, before sending the certificate to the server after a short delay." -- ...before sending the certificate to the *client*?

5.7. "After a delay of Max-Age, the client SHOULD resend the identical CSR to the server." -- Just for my understanding: Does the submission of a specific CSR always lead to the same output, or can it happen (e.g., if the client submits an identical CSR weeks or months later) that the client would get a different output?

5.7. "... or the client abandons for other reasons." -- Does the client need to signal in some way when it wants to abandon?

5.8. "containing a CBOR array with four items Section 5.3" -- Missing word between 'items' and 'Section'

5.8. "containing a CBOR array with four items Section 5.3" -- Do the two representations (each consisting of two CBOR array items) have to be in a particular order or can they appear in any order?

6. "DTLS Transport Protocol" -- This section seems to have the same topic as section 4. Merge section 4 into section 6?

6. "In a constrained CoAP environment, endpoints can't always afford to establish a DTLS connection for every EST transaction." -- I'm not aware of any requirement that says CoAP clients must establish a new DTLS connection for every request...

6. "To alleviate this situation, an EST-coaps DTLS connection MAY remain open for sequential EST transactions." -- An application layered on top of CoAP shouldn't mandate a particular way in which DTLS is used.

8. "Parameters" -- An application layered on top of CoAP shouldn't mandate CoAP congestion control parameters.

10.2. "This EST resource is used to query and return the supported EST resources of a CoAP server." -- Is there any specification for how to query and return the supported EST resources?

I didn't review the appendices.

Klaus

_______________________________________________
Ace mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ace