On Fri, Feb 22, 2019 at 09:00:05PM +0000, Panos Kampanakis (pkampana) wrote:
> 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.
I think there is enough flexibility in our specifying a "new transport for
EST" that we do not need to be strictly bound to the EST-mandated
authentication mechanisms. That said, I'm not sure I have any other
options handy than mutual cert auth...
> > 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.
This sort of detail is good to have stated clearly in the document.
-Ben
> > 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 <[email protected]> On Behalf Of Klaus Hartke
> Sent: Tuesday, February 12, 2019 12:38 PM
> To: Jim Schaad <[email protected]>
> Cc: [email protected]
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/ace
>
> _______________________________________________
> Ace mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
