Thanks Ben. I addressed your content-format order comment in the next iteration of the draft by saying
> The two representations (each consisting of two CBOR array items) do > not have to be in a particular order since each representation is > preceeded by its Content-Format ID. Panos -----Original Message----- From: Benjamin Kaduk <ka...@mit.edu> Sent: Sunday, February 24, 2019 7:08 PM To: Panos Kampanakis (pkampana) <pkamp...@cisco.com> Cc: Klaus Hartke <har...@projectcool.de>; Jim Schaad <i...@augustcellars.com>; ace@ietf.org Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est 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%3 > Aissue+%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-c > oap-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 <ace-boun...@ietf.org> On Behalf Of Klaus Hartke > Sent: Tuesday, February 12, 2019 12:38 PM > To: Jim Schaad <i...@augustcellars.com> > Cc: ace@ietf.org > 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 > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
