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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 08 October 2020 17:42 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000E23A0B76 for <ace@ietfa.amsl.com>; Thu, 8 Oct 2020 10:42:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KR3fcjNJq-3 for <ace@ietfa.amsl.com>; Thu, 8 Oct 2020 10:42:43 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECA523A0B75 for <ace@ietf.org>; Thu, 8 Oct 2020 10:42:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9EA67389B7; Thu, 8 Oct 2020 13:48:08 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jBcb-cbgv4aY; Thu, 8 Oct 2020 13:48:07 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 97CA1389B5; Thu, 8 Oct 2020 13:48:07 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3395318B; Thu, 8 Oct 2020 13:42:40 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Ace Wg <ace@ietf.org>
CC: Kent Watsen <kent+ietf@watsen.net>
In-Reply-To: <AM0PR10MB24183F163B988B1BE3B4B976FE0B0@AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM>
References: <CAEpwuw09Ud-LBNhAc5591mbB+MpOOaeUKBEKfuRW5oJGCs5qZQ@mail.gmail.com> <BN7PR11MB254786CF6D99AF95C1EF0089C90C0@BN7PR11MB2547.namprd11.prod.outlook.com> <AM0PR10MB24183F163B988B1BE3B4B976FE0B0@AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Thu, 08 Oct 2020 13:42:40 -0400
Message-ID: <32742.1602178960@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/vElrZDDId21KZ-Yck2MJsW7imkU>
Subject: Re: [Ace] Call for adoption draft-msahni-ace-cmpv2-coap-transport-01
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Oct 2020 17:42:45 -0000

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.

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/.

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.

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.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide