Re: [Ace] Call for adoption draft-msahni-ace-cmpv2-coap-transport-01

Resending it with correct formatting:
===========================================================
Hi Michael,
Thanks for going through the draft. Your feedback is very helpful. I
just want to reiterate that the scope of this draft is only how to use
CoAP as a transport protocol for CMP. The work on defining how CMP
protocol itself should work on constrained devices is being done in
the "Light Weight CMP Profile"
https://datatracker.ietf.org/doc/draft-ietf-lamps-lightweight-cmp-profile/.
Some of your suggestions should be discussed in the context of the
LightWeight CMP profile draft.

Please see my comments inline:

> ---------- Forwarded message ----------
> From: Michael Richardson <mcr+ietf@sandelman.ca>
> To: Ace Wg <ace@ietf.org>
> Cc: Kent Watsen <kent+ietf@watsen.net>
> Bcc:
> Date: Thu, 08 Oct 2020 13:42:40 -0400
> Subject: Re: [Ace] Call for adoption draft-msahni-ace-cmpv2-coap-transport-01
>
> Hi, I've read draft-msahni-ace-cmpv2-coap-transport-01.
>
> I think that the major reason to use CMP instead of EST is avoid the need for
> DTLS on the constrained client.  As such, use of coaps seems far less
> interesting.
>
> In particular, I think that section 4.2, on CoAPs to HTTPS proxy
> is just wrong.   I don't see why we need any kind of end to end trust
> assertions given that it is CMP.   MITM trust for anchors seems a rather
> unwanted thing.
>
> Why can't the EE just be configured to speak to a CoAPS enabled RA (using
> it's name), and then transported to the CA via HTTPS.  It is not like
> having the TLS MITM proxy is reducing crypto effort for any entity.

[M.S.] Section 3 covers the case where EE can talk to RA directly over
CoAPs, the CoAPs to HTTPs proxy in section 4.2 is for the use case
where changes to the existing RA deployment are not desired due to
operational overheads of upgrading the RA to something that supports
CoAP/CoAPs. CoAPs to HTTPs proxy is not something that is required for
the functionality but rather an option to help with easy adoption of
the "Lightweight CMP profile" and CMPv2 protocol for constrained
devices. I will work on making it more clear what are the pros and
cons of using a proxy vs direct communication.

> I have no fundamental objection to this work, and I think that it should be
> adopted.
>
> But, I think that it is worth doing more than just s/http/coap/.

[M.S.]  I agree with that.

>
> I think that end points should be specified, as well as resource discovery.
> I was writing some text (not yet pushed) for BRSKI-ASYNC-ENROLL
> about how to do CMP for the "Delay Tolerant Networks" that AE envisions.

[M.S.]  I will add the endpoint definitions and make resource
discovery more clear in the draft.

>
> On constrained networks, there are some significant tussles between allowing
> certificate renewal to be driven by a state machine on the client device vs
> by the network itself.
>
> Client devices know when they are awake and can receive renewals, but they
> don't know if the network has capacity at that time.
>
> On the other hand, the network knows when it has bandwidth, and it can manage
> things.
>
> My approach to CMP would be define a set of resources and then use CORECONF
> to access/update them.   I think that:
>
> https://www.ietf.org/id/draft-ietf-netconf-trust-anchors-13.html
> https://www.ietf.org/id/draft-ietf-netconf-keystore-20.html
>
> The later offers a CSR leaf that a RA could *retrieve*, and then when a
> certificate is available, could push into the keystore.
> This also deals with what the trust anchors are.
>
> It could be that some additional leafs are needed to implement some of the
> additional CMP specific functionality.

[M.S.] This is something that I believe is not in the scope of this
draft, This draft only defines how to use the CoAP transport for
carrying the CMP messages. When and what CMP messages are sent should
come under the CMP protocol implementation itself.

>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace