[Ace] Review draft-ietf-ace-coap-est

Jim Schaad <ietf@augustcellars.com> Sun, 01 July 2018 13:33 UTC

Return-Path: <ietf@augustcellars.com>
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 8DF0A1277CC; Sun, 1 Jul 2018 06:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 O1jQN9ysnRpr; Sun, 1 Jul 2018 06:33:47 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35107130DFA; Sun, 1 Jul 2018 06:33:47 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 1 Jul 2018 06:30:36 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: draft-ietf-ace-coap-est@ietf.org
CC: 'ace' <ace@ietf.org>
Date: Sun, 01 Jul 2018 06:33:38 -0700
Message-ID: <032f01d41140$20027c80$60077580$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AdQQomo17j3U+ofJS2Sv3RAe718IaA==
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/7oxEgOR4r2of90Ghiuo9qhonhtE>
Subject: [Ace] Review draft-ietf-ace-coap-est
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.26
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: Sun, 01 Jul 2018 13:33:50 -0000

* In section 4.1 I have a question about what you are using for payload
content encoding.  Part of this might just be a question of how you plan to
move from ASN.1 to CBOR at some point in the future.  I think that it would
necessitate doing new media-types in that event.  You appear to be doing a
CBOR bstr wrapping on the ASN.1 encoding payload.  I don't believe that
there is any reason for doing this.  I would expect that the payload would
be the ASN.1 w/o any ASN.1.  It is highly possible that I am just
mis-reading what the text says and this is what you say.

* In section 5.0 - As written, the example of doing a query against
/.well-known/core does not match my understanding of what would be return.
It should only return those resources which have the rt field set on them.
I do not understand why you believe that the following lines MAY be
returned.  Clarification of why you think this is true would be appreciated.

* Section 6 - Is there a need to have all of this description around
TLS-unique?  Do you have a reason to believe that people are going get this
implemented wrong?

* Section 7 - I think the figure has an error associated w/ it.  The CA
should be tied to the EST Server and not to the Registrar

* Section 7 - Your language is a bit sloppy around the terms of POP and POP
linking.  Unless it is really badly behaved, POP should never be broken by
an RA.  The POP is the signature on the request and not tied to the TLS
channel.  The POP linking is tied to the TLS channel and is broken by the
changing of the TLS sessions (client <-> RA,  RA <-> CA) 

* Section 7 - It is not clear to me that the SHOULD on reassembly of
fragmentation is not a MUST.  I doubt that any EST server is going to be
able to deal with getting fragments of requests from a registrar in separate
messages.  This would be compounded if the proxy is handling multiple
sessions at the same time. 

* Section 7 - It should be possible that when doing key generation for the
protection of the private key to be end-to-end and it should not be
necessary for the Proxy to decrypt and then re-encrypt the private key.  It
should not matter for this if one does either symmetric or asymmetric
encryption of the private key.

* Section 7 - It is very possible that the private key generation function
would be hosted on the proxy and not at the CA.  I think that you might want
to describe this as a normal configuration.  (Just spotted this in the
Security considerations.  I think it should be here as well.)

* Section 9.1 - application/multipart-core should not be in the table of
items for IANA to register.  This is being done in a different document.  If
you want this table as a whole then it needs to be moved out of IANA
considerations.

* Section 9.2 - please expand this text some.  You might want to look at
https://tools.ietf.org/html/rfc7390#section-6.1 for a template.


Jim