[core] Review on draft-ietf-core-oscore-groupcomm--08

[Jim Schaad <[e-mail]>]

* Section 3 - Is there supposed to be a signal that an endpoint does or does
not support this?  As part of the entity context?

*  In section 3.2 - the second paragraph is not completely correct.  The
only reason that the behavior of sequence numbers is going to change would
be if the client and server send messages back and forth that they would not
have normally wrapped with the group key.  For the purpose of getting large
content via blockwise this would not be the case.   I don't believe that you
are suggesting that these keys should be used for doing pair wise key
establishment for things which would not be thought of as, in theory, part
of a multicast application.

* Section 10.4 - If client sends request in security context A, the server
MUST NOT use reflection of the PIV if it is going t reply in security
context B.  Otherwise there is a chance that the same IV would be used twice
in security context B.

* Appendix A bullet #2 - This says that /.well-known/core cannot be part of
two different application groups.  That may be fine depending on how an
application group is defined but it may not if one says that an application
group member needs to do a search, inside of the application group, for
resources from that resource.

* Appendix E.1 - The second and third paragraphs seem to say the exactly
opposite things.  A very close reading shows that they don't, but it is hard
on first read to detect that. 

* Appendix E.1 - I disagree with the recommendation of paragraph 3 in this
section.  The server would care about freshness only in the question of
should it be processed and not in terms of how to process the response
message.  Using the reflected PIV seems to be perfectly reasonable if the
server is willing to process the request.  Given that responses almost never
go via a multicast channel, a client would not see any responses from the
server except to itself.  The client has the ability to know when it sent
the request and thus knows how long the response took and if it would
consider it to be fresh enough.  ** Same argument for E.2

* Appendix E.2 - This description omits one potential step that I would
consider to be vital in this method.  That is you receive the message, set
the sequence number, DROP THE REQUEST, and then wait for new requests which
have a higher sequence number.  There is still the replay attack, but that
also exists for E.1 as well.

* Appendix E.3 - May want to add a note that there is no confusion about why
the 4.01 is being returned because the message will be protected by the
group security key so it is known that the crypto security is just fine.

* Appendix E.3 - The idea of doing the echo sync process following a "large
enough gap" in seen sequence numbers can potentially be problematic if you
are also saying that a client may be doing a large number of unicast
operations to a number of servers.  This has the ability to consume that gap
faster than one might think.  This should be added here.  Trade-offs between
a sequence number gap and a time gap should probably be discussed.

* Appendix E.3 - para 2 - The <group Id, sender ID> should be stored with
the Echo Option value by the server and the Echo Option value should only be
accepted if the same sender produced the message.  An implication of this is
that a roll over to a new key set means that all of the old Echo Option
values would disappear, but you would still have the required freshness as
use of the new crypto context means that there is a limit as to when it
could have first been requested.  Note that I think that this foils the
section 10.7 attack as while an attacker can get the value, it does them no
good because they cannot produce the required signature.

*Appendix E.3 - The Echo option MUST NOT be sent in a multicast message
because it makes no sense to any but one server.

Jim