[Ace] Review for draft-ietf-ace-key-groupcomm-04
Jim Schaad <ietf@augustcellars.com> Thu, 30 January 2020 23:16 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 2B4971200F7; Thu, 30 Jan 2020 15:16:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 hSTDkFNTy8W1; Thu, 30 Jan 2020 15:16:46 -0800 (PST)
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 0C0BC120026; Thu, 30 Jan 2020 15:16:43 -0800 (PST)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 30 Jan 2020 15:16:37 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: draft-ietf-ace-key-groupcomm@ietf.org
CC: ace@ietf.org
Date: Thu, 30 Jan 2020 15:16:36 -0800
Message-ID: <010c01d5d7c3$52ea77b0$f8bf6710$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdXQCzoDRJGtjzwzSJSGfp6QenWJMA==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/mR-qwWEhmmOFIVL2ToH5pc2GXqs>
Subject: [Ace] Review for draft-ietf-ace-key-groupcomm-04
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, 30 Jan 2020 23:16:47 -0000
This is not a finished review, but I wanted to get it out Jim Section 1 - last paragraph - the first sentence in this paragraph is giving me fits trying to understand it. I would suggest something, but I really don't understand it. General - Update the reference to RFC 7049 to the bis draft. Section 3.1 - Should we try and harmonize the scope format here with either the format in MQTT or with the one that Carsten once proposed. The multiplicity of scope formats is going to become a problem at some point. Section 3.1 - It might make sense to move the contents of the last paragraph of 'scope' up to the two points dealing with the elements. I had a brief moment where I thought REQ1 and REQ2 conflicting with the CBOR array. Section 3.2 - I think the definition of 'exp' is incorrect. Did you mean to use 'exi'? Section 3.2 - for scope - if the format is the same as in Section 3.1 - just say that and omit the details. Section 3.3 - Does REQ3 indicate that the profile is supposed to say that the set of valid algorithms is defined or that a set of identifiers different than that defined in the COSE Algorithm registry can be used. An example would be a text version of object identifiers. My current reading is that the latter is correct. Section 3.3.3 - I don't think that you can return an rsnounce at this point. There is nothing that ensures that one knows who the client is and thus one cannot tie the nonce to any specific client. Depending on what you are trying to prove with the POP interaction this may not be provable with this. Section 4.1 - Now does one enforce the MUST NOT for the resource name of /ace-group? Section 4.1.2.1 - I think that this is the "join". Using that word here will clarify what is going on. Section 4.1.2.1 - Once again - tell me why I care about scope in this location. Section 4.1 - I am not sure, but I think that I might want to suggest putting a node in the path between guid and the node id for a single end point. That is /ace-group/gid/nodes/node. This allows for one to not deal with potential name collisions with the other nodes under gid. Section 4.1.3.1 - Why can get_put_keys not be an empty array? Should this be a bad request error if it is empty? * - Should a client be able to ask for a previous set of keying material? Consider the case of a client having key material n, missing update n+1 and getting update n+2. The client then gets a message encrypted to update n+1. It never saw the material and thus cannot decrypt the message. Section 4.3 - first para - another condition is if it discovers that new keying material has been issued. (Either as a message with a new epoch or a notification from the server.) While this is covered in the second paragraph it is not clear that the client is going to stop using the key material in that case. Section 4.3 - para 3 - Is there a difference between not being able decrypt because of decryption failure rather than on the basis of not having key material to decrypt. That is type of failure makes a difference Section 4.4 - Policy can be that the KDC does a general rekey instead of just doing an individual rekey Section 6 - gkty does not match description - should be text string not byte string