Subject: Re: [Ace] draft-vanderstok-ace-coap-est-03

From: peter van der Stok <[email-masked]>
Date: Tue, 02 Jan 2018 12:00:25 +0100

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.