Hi Hannes,
Happy new year.
Many thanks for your comments; See below for my "late" reactions
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)"
Thanks for the suggestion; Possibly my co-authors will come up with
other suggestions.
Abstract: Here is my proposal:
I understand your wish for terseness. And I agree with that purpose.
FROM your suggestion:
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.
I arrived at:
Abstract
Enrollment over Secure Transport (EST) [RFC7030] is used as a
certificate management protocol over HTTPS.
Low-resource devices often use the lightweight Constrained
Application Protocol (CoAP) [RFC7252] for message exchanges. This
document defines how to transport EST payloads over secure CoAP (EST-
coaps). This allows low-resource constrained devices to re-use
existing EST functionality. Example low-resource use cases for EST
are: secure bootstrapping and certificate enrollment.
----
REASON:
The use cases were pretty relevant for the discussion in ACE
As such, I would suggest to change the text in the introduction:
TO:
1 [14]. INTRODUCTION
Added your phrases below
"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.
The two paragraphs are now preceded with an EDNote for removal
suggestion
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 [11]] 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.
Paragraph below has been moved to the end of transport protocol section
Support for Observe CoAP options [RFC7641 [12]] 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.
Personally, I feel happier by leaving it in to acknowledge the cut and
paste from RFC7030
Many of the concepts in this document are taken over from [RFC7030
[1]].
Consequently, much text is directly traceable to [RFC7030 [1]].
The same
document structure is followed to point out the differences and
commonalities between EST and EST-coaps.
2 [15]. EST OPERATIONAL DIFFERENCES
I would move this text into the (now shorter) introduction.
moved as subsection of the introduction.
SECTION 4 [16]. 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 [1] 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.
The server-side key generation is wanted by several applications, I
understood.
One of my co-authors may react here.
It was explained to me that a small server may be equipped with a large
enough key during the manufacturing process,
but needs to generate new keys during operation with the aid of a key
generation server.
4.3 [17]. COAP RESPONSE CODES
Is it really necessary to create a dependency to
[I-D.hartke-core-pending [13]] since this means that this document
cannot be completed for an extended period of time?!
Good remark.
The reference is now informative. The new "pending" draft will specify
that a server may generate additional information
when returning 5.03
4.4 [18]. 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.
For http users, "block" is pretty new and needs some explanatory
introduction for stand alone understanding.
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.
Absolutely correct. New text is:
[RFC6347] states that to avoid
using IP fragmentation, which involves error-prone datagram
reconstitution, invokers of the DTLS record layer SHOULD size DTLS
records so that they fit within any Path MTU estimates obtained from
the record layer.
Like to keep this text to introduce the subject
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.
Expect the new text above to better cover the subject.
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.
text says between 500 and 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.
Complete agreement.
7 [19]. PROXYING
Why are you introducing proxy behaviour in EST over CoAP when it is
not available in classical EST?
It is an aspect that comes into play once you add coap as a protocol
next to http.
Installations will probably support both.
Can PoP work with a HTTP/CoAP proxy?
Some additional text may be interesting to cover that aspect.
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?
Let me think about that with my co-authors. May be there are other
opinions on this subject?
Possibly, it is not much additional text.
Ciao
Hannes
Thanks Hannes
The text suggestions and discussions
help a lot.
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
