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

[Klaus Hartke <[e-mail]>]

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