Hi Peter, Hi co-authors, Thanks a lot for the quick update. In my opinion the document made a big step forward.
I nevertheless have a few comments: Would it make sense to expand the title of the draft to something like "Using Enrollment over Secure Transport (EST) over the Constrained Application Protocol (CoAP)" Abstract: Here is my proposal: FROM: Abstract Low-resource devices in a Low-power and Lossy Network (LLN) can operate in a mesh network using the IPv6 over Low-power Wireless Personal Area Networks (6LoWPAN) and IEEE 802.15.4 link-layer standards. Enrollment over Secure Transport (EST) [RFC7030<https://tools.ietf.org/html/rfc7030>] is used for authenticated/authorized endpoint certificate enrollment (and optionally key provisioning) through a Certificate Authority (CA) or Registration Authority (RA). Example low-resource uses cases for EST are: secure bootstrapping and certificate enrollment. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) [RFC7252<https://tools.ietf.org/html/rfc7252>] for message exchanges. This document defines how low-resource devices are expected to use EST over secure CoAP (EST-coaps). 6LoWPAN fragmentation management and extensions to CoAP registries are needed to enable EST-coaps. TO: ---- Abstract Enrollment over Secure Transport (EST) has been defined in RFC 7030 and is used as a certificate management protocol over HTTPS. This specification defines how to convey EST payloads over the Constrained Application Protocol (CoAP). This allows resource constrained Internet of Things devices to re-use existing EST functionality. ---- REASON: 802.15.4 is only one networking technology EST over CoAP can be used over but there is nothing in CoAP over EST that requires 802.15.4 nor 6LoWPAN. For that reason I prefer to keep it more generic. The same is true for the introduction where you repeat this story again. As such, I would suggest to change the text in the introduction: FROM: 1<https://tools.ietf.org/html/draft-vanderstok-ace-coap-est-03#section-1>. Introduction Enrollment over Secure Transport (EST) [RFC7030<https://tools.ietf.org/html/rfc7030>] is used for authenticated/authorized endpoint certificate enrollment (and optionally key provisioning) through a Certificate Authority (CA) or Registration Authority (RA). This functionality is also needed for low resource devices. IPv6 over Low-power Wireless Personal Area Networks (6LoWPANs) [RFC4944<https://tools.ietf.org/html/rfc4944>] on IEEE 802.15.4 [ieee802.15.4<https://tools.ietf.org/html/draft-vanderstok-ace-coap-est-03#ref-ieee802.15.4>] wireless networks is becoming common in many industry application domains such as lighting controls. Although IEEE 802.15.4 defines how security can be enabled between nodes within a single mesh network, it does not specify the provisioning and management of the keys. Therefore, securing a 6LoWPAN network with devices from multiple manufacturers with different provisioning techniques is often tedious and time consuming. An example use case is the application of Bootstrapping of Remote Secure Infrastructures (BRSKI) [I-D.ietf-anima-bootstrapping-keyinfra<https://tools.ietf.org/html/draft-vanderstok-ace-coap-est-03#ref-I-D.ietf-anima-bootstrapping-keyinfra>]. The low resource aspects are detailed for 6tisch in [I-D.ietf-6tisch-minimal-security<https://tools.ietf.org/html/draft-vanderstok-ace-coap-est-03#ref-I-D.ietf-6tisch-minimal-security>] and [I-D.ietf-6tisch-dtsecurity-secure-join<https://tools.ietf.org/html/draft-vanderstok-ace-coap-est-03#ref-I-D.ietf-6tisch-dtsecurity-secure-join>]. Constrained networks use DTLS [RFC6347<https://tools.ietf.org/html/rfc6347>], CoAP [RFC7252<https://tools.ietf.org/html/rfc7252>], and UDP instead of TLS [RFC5246<https://tools.ietf.org/html/rfc5246>], HTTP [RFC7230<https://tools.ietf.org/html/rfc7230>] and TCP. EST-coaps replaces the invocations of TLS and HTTP by DTLS and CoAP invocations thus enabling EST for CoAP-based low-resource devices. Although EST-coaps paves the way for the utilization of EST for constrained devices on constrained networks, some devices will not have enough resources to handle the large payloads that come with EST-coaps. The specification of EST-coaps is intended to ensure that EST works for networks of constrained devices that choose to limit their communications stack to UDP/CoAP. It is up to the network designer to decide which devices execute the EST protocol and which not. Because the relatively large EST messages cannot be readily transported over constrained (6LoWPAN, LLN) wireless networks, this document specifies the use of CoAP Block-Wise Transfer ("Block") [RFC7959<https://tools.ietf.org/html/rfc7959>] to fragment EST messages at the application layer. Support for Observe CoAP options [RFC7641<https://tools.ietf.org/html/rfc7641>] is out-of-scope for this document. Observe options could be used by the server to notify clients about a change in the cacerts or csr attributes (resources) and might be an area of future work. TO: 1<https://tools.ietf.org/html/draft-vanderstok-ace-coap-est-03#section-1>. Introduction Enrollment over Secure Transport (EST) [RFC7030<https://tools.ietf.org/html/rfc7030>] is used for certificate management (and optionally key provisioning) through a Certificate Authority (CA) or Registration Authority (RA). This functionality is also needed for low resource devices. "Classical" EST uses HTTPS and this specification defines a new transport for EST using CoAP. It also profiles the use of use of EST to a smaller subset. I would omit the following two paragraphs from the introduction since you are discussing them again in more detail in Section 4.4. Although EST-coaps paves the way for the utilization of EST for constrained devices on constrained networks, some devices will not have enough resources to handle the large payloads that come with EST-coaps. The specification of EST-coaps is intended to ensure that EST works for networks of constrained devices that choose to limit their communications stack to UDP/CoAP. It is up to the network designer to decide which devices execute the EST protocol and which not. Because the relatively large EST messages cannot be readily transported over constrained (6LoWPAN, LLN) wireless networks, this document specifies the use of CoAP Block-Wise Transfer ("Block") [RFC7959<https://tools.ietf.org/html/rfc7959>] to fragment EST messages at the application layer. I would also omit the following paragraph since it is not clear to me why you are discussing one design item that has not been added to the spec while there are many others as well that have not been mentioned. Support for Observe CoAP options [RFC7641<https://tools.ietf.org/html/rfc7641>] is out-of-scope for this document. Observe options could be used by the server to notify clients about a change in the cacerts or csr attributes (resources) and might be an area of future work. Terminology: I would remove this paragraph since it does not add any value. Many of the concepts in this document are taken over from [RFC7030<https://tools.ietf.org/html/rfc7030>]. Consequently, much text is directly traceable to [RFC7030<https://tools.ietf.org/html/rfc7030>]. The same document structure is followed to point out the differences and commonalities between EST and EST-coaps. 2<https://tools.ietf.org/html/draft-vanderstok-ace-coap-est-03#section-2>. EST operational differences I would move this text into the (now shorter) introduction. Section 4<https://tools.ietf.org/html/draft-vanderstok-ace-coap-est-03#section-4>. Protocol Design and Layering You write: o Server-side key generation messages, to provide a private client- identity key when the client is too restricted or because of lack of an entropy source. [EDNOTE: Encrypting these keys is important. RFC7030<https://tools.ietf.org/html/rfc7030> specifies how the private key can be encrypted with CMS using symmetric or asymmetric keys. Mention how symmetric key can be derived for EST server side key generation from the TLS KEM draft.] I consider server-side key generation (for public key crypto) as problematic since the server obviously gets to see the private key (something that can be avoided by the use of asymmetric crypto and client-side generation of secrets). With ECC (which is what I would recommend for use on IoT devices due to the smaller key size) the key pair generation is also much simpler. You indeed require a TRNG on the device but you need that anyway. For public key crypto the recommended ciphersuite uses an EDHE and DTLS also exchanges nonces in the handshake. In a nutshell, if you don't have a hardware-based random number generator then you are in trouble. The good thing is that you get these nowadays in hardware even with the most basic MCUs. 4.3<https://tools.ietf.org/html/draft-vanderstok-ace-coap-est-03#section-4.3>. CoAP response codes Is it really necessary to create a dependency to [I-D.hartke-core-pending<https://tools.ietf.org/html/draft-vanderstok-ace-coap-est-03#ref-I-D.hartke-core-pending>] since this means that this document cannot be completed for an extended period of time?! 4.4<https://tools.ietf.org/html/draft-vanderstok-ace-coap-est-03#section-4.4>. Message fragmentation There is a lot of text in this section for just saying that you want to use block-wise transfer. I also don't think you need to explain what block-wise transfer is. Regarding the statements being made: It almost sounds like you are saying that you cannot use EST over CoAP without block-wise transfer and I don't believe that's is correct. First, there are a number of connectivity technologies that do not have a very small MTU size and those should be supported as well. Second, you discuss IEEE 802.15.4 specifically. You start by saying that "Each DTLS record MUST fit within a single datagram". You then say that: To avoid using IP fragmentation, which is not supported by 6LoWPAN, invokers of the DTLS record layer MUST size DTLS records so that they fit within any Path MTU estimates obtained from the record layer. This is what the DTLS specification says and does not need to be repeated here. Here is the text from RFC 6347 " In order to avoid IP fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any PMTU estimates obtained from the record layer. " The difference between the two sentences is that you are saying that DTLS must perform fragmentation whereas the DTLS RFC says should. I fear that you are modifying the behaviour of the DTLS RFC. That could be a problem. My naïve understanding of 6LoWPAN is that it supports fragmentation while you claim that it doesn't. So, what is the story? I wonder how you came to the following conclusion: At the CoAP level it may be difficult to "cut" the messages exactly in such a way that they fit correctly and so it might make more sense to let the lower layers, such as DTLS and 6LoWPAN to do their job. In addition, invokers residing on a 6LoWPAN over IEEE 802.15.4 network SHOULD attempt to size CoAP messages such that each DTLS record will fit within one or two IEEE 802.15.4 frames. Regarding the size indications of certificates I have so far had cases where 256-bit curves have a size of ~620 bytes but not 1000 bytes. Of course, you can add all sorts of extensions and long fields to the cert but maybe that's not a great idea if you care about over the wire overhead. 7<https://tools.ietf.org/html/draft-vanderstok-ace-coap-est-03#section-7>. Proxying Why are you introducing proxy behaviour in EST over CoAP when it is not available in classical EST? Can PoP work with a HTTP/CoAP proxy? Editorial: s/COAP/CoAP Final remark: would it make sense to support CoAP over TCP in the draft since we are about to finish the specification work? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
