[Ace] draft-vanderstok-ace-coap-est-03

[Hannes Tschofenig <[e-mail]>]

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.