Subject: [Ace] Review for draft-ietf-ace-key-groupcomm-04

From: Jim Schaad <[email-masked]>
Date: Thu, 30 Jan 2020 15:16:36 -0800

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