Subject: [Ace] draft-ietf-ace-cmpv2-coap-transport-00.txt - do not mention V" of CMP in the document

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 5 Mar 2021 17:36:43 +0000

Mohit

We introduced V3 of CMP in draft-ietf-lamps-cmp-updates-08 Section 2.15. The version of CMP is not relevant to the CoAP transport, I guess. Therefore, I suggest to  remove references to the CMP version from your draft, especially from the title. If you want to exclude CMP V1 as specified in RFC 2510 from the scope of your draft, this is fine with me as well.

Hendrik

---

From: Mohit Sahni <[email-masked]>
Date: Wed, 10 Mar 2021 10:44:23 -0800

Hi Hendrik
Thanks for the update, I will make changes to remove the CMP version
references from the document. I think we can exclude CMPv1 from the
scope as it will obsolete soon.

Thanks
Mohit

---

From: David von Oheimb <[email-masked]>
Date: Thu, 11 Mar 2021 18:10:52 +0100

Hi Mohit,

thanks a lot for providing that draft. It looks very good already.

Good point by Hendrik to replace "CMPv2" by "CMP" since the version
really does not matter here.

I'd suggest dropping the hyperlinked reference from the abstract and
a couple of further adaptations to the abstract, such that it becomes

   This document specifies use of the Constrained Application Protocol
   (CoAP) for transferring Certificate Management Protocol (CMP) messages.
   It details the respective option mentioned in the Lightweight CMP Profile.
   CMP defines the interaction between various PKI entities for certificate
   enrollment and management.  CoAP is an HTTP-like client-server protocol
   for use in constrained devices in IoT space.

Further mostly very minor improvement suggestions are given below.

Cheers,
    David

Section 1:

transport -> transfer (several times)
encryption of messages -> protection of messages
between CAs -> between RAs

Section 2:

PKIMesssage -> PKIMesssages

I do not understand what you want so say here:
> An EE MUST verify the configured Root CA
> certificate against the Root CA certificate of the discovered entity
Likely you meant:

An EE MUST verify the certificate of the discovered entity
against a configured trust anchor (Root CA certificate)

The URI's for CoAP resources should start ->
The only difference is that the URIs for CoAP resources MUST start

should return a "2.05 Content" ->
MUST return a "2.05 Content"
(or are there other options in case of success?)

application/pkixcmp -> "application/pkixcmp"

for the possible changes -> for potential changes

Block Wise -> Block-Wise (in title of 2.6)
Block Wise -> block-wise (in body of 2.6)

header body and optional fields ->
header, body, protection, and extraCerts including many optional and
potentially bulky fields

outgoing interface -> interface
(because this may also happen for responses)

maybe leave out?   that are exchanged between EEs and RAs or CAs

maybe weaken?:   mode MUST be used -> mode SHOULD be used

then, it -> then it

Proxy opens -> the proxy opens

maybe leave out?   from EEs to RAs or from EEs to CAs

Section 3:

the encryption and authentication of the messages but in cases when ->
protecting message contents, in case

7.1 and 7.2 -> 7.2 and 7.3
(for draft 03 at least)

overhead of using DTLS connection -> overhead of setting up DTLS connections

Sections 4 and 5:

CoAP to HTTP -> CoAP-to-HTTP
(several times)

significant changes -> changes

Announcements Messages -> announcement messages

MUST be positioned -> SHOULD be positioned
(else the recommendation given next makes no sense)

between CAs and RAs -> between RAs and CAs

UDP based -> UDP-based
(two times)

CoAPs to HTTPS -> CoAPS-to-HTTPS

HTTPS protocol, -> HTTPS.

however client SHOULD be configured to trust the CA certificate used by
proxy to sign the Man in the Middle (MITM) certificate for certificate
chain validation ->
The client SHOULD be configured with a trust anchor suitable for
validating the DTLS server certificate used by the proxy

I doubt if the paragraph
>    However, the CoAP protocol which
>    uses UDP as layer 4 transport is vulnerable to many issues due to the
>    connectionless characteristics of UDP itself.  The Security
>    considerations for CoAP protocol are mentioned in the [RFC7252 <https://tools.ietf.org/html/rfc7252>].
>    Using a CoAP to HTTP proxy mitigates some of the risks as the
>    requests from the EE's can terminate inside the trusted network and
>    will not require the server to listen on a UDP port making it safe
>    from UDP based address spoofing, Denial of Service, and amplification
>    attacks due to the characteristics of UDP.
makes sense because, as you wrote before, CMP is already self-contained
in terms of security.
Therefore I think it should be sufficient to say for instance:

Therefore security issues of CoAP due to using UDP do not carry over to the CMP layer 
except for the vulnerability to Denial-of-Service attacks.

Section 6:

content-type application/pkixcmp -> content type "application/pkixcmp".

---

From: David von Oheimb <[email-masked]>
Date: Thu, 11 Mar 2021 18:50:52 +0100

P.S.

One of the few major comments I gave below was pertaining to the
security considerations.
AFAICS the only security issue induced by using CoAP/UDP with CMP is the
increased vulnerability to DoS attacks.

To reduce the DoS risk in particular with the need to split larger
messages into smaller chunks to re-assemble them later,
it should be pretty helpful if both sides of the connection minimize the
number and contents of CMP message fields as far as possible,
for instance by leaving out unimportant optional fields, using short
strings, preferring PBM-based protection, and generally (also for the
certificates being managed) using ECC rather than RSA.
I suggest placing some remark like this in sections 2.6 and/or 5.

On 11.03.21 18:10, David von Oheimb wrote:
> however client SHOULD be configured to trust the CA certificate used
> by proxy to sign the Man in the Middle (MITM) certificate for
> certificate chain validation ->
> makes sense because, as you wrote before, CMP is already
> self-contained in terms of security.

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 12 Mar 2021 10:07:47 +0000

David, Mohit

> Von: David von Oheimb <[email-masked]> 
> Gesendet: Donnerstag, 11. März 2021 18:51
>
> To reduce the DoS risk in particular with the need to split larger messages into smaller chunks to re-assemble them later,
> it should be pretty helpful if both sides of the connection minimize the number and contents of CMP message fields as far as possible,
> for instance by leaving out unimportant optional fields, using short strings, preferring PBM-based protection, and generally (also for the certificates being managed) using ECC rather than RSA. 

I would not put too many CMP specific recommendations regarding profiling CMP into the CoAP draft to keep the scope focused. I think a general recommendation to try to keep the CMP messages lean should do.

Hendrik