Subject: [core] Review on draft-ietf-core-oscore-groupcomm-09

From: Jim Schaad <[email-masked]>
Date: Thu, 2 Jul 2020 15:07:09 -0700

* Section 1 s/Such decision can/Such decisions can/

* Section 1 - You say that using pairwise return significantly reduces the
overhead.  I do not understand how this can work.  It seems to me that at a
minimum you are going to use more memory on each device in order to hold at
least some of the pair-wise context information.  

* Section 2.1.4 - You really only need to have the key capabilities
specified once.  It could either be separate or part of the algorithm
information.  Duplicating the information does not really help anything.

* Section 2.3.1 - I was expecting to be using the other coordinate scheme.
I think you might want to run this pass the lwig group because they are
mapping the Ed25519 curve to something other than X25519.

* Section 2.3.2 - The last paragraph does not make sense unless you note
that the recipient is a group-comm recipient and not the pair wise
recipient.  Additionally, this statement has nothing specific to do with
pair-wise keying per say.  The same statement exists if, for example, a
client does a large set of block-wise transfers to a server using the group
key.  The sequence number would jump by quite a bit and other recipients
might think that they missed something and require an echo.  Depending on
the number of servers that request the echo response, that in itself might
cause the next multicast message to again be required to use the echo
response option.

* Section 2.4 - I am worried about how this requirement is stated.  It says
that the immutable part needs to be saved, but it does not say anything
about the changeable portion - for example the sequence number.  Saving one
part and not the other is going to be bad news on a reboot if the same
pieces are going to be re-used.

* Section 2.4.2 - What is an implementation supposed to do if integers do
not support wrapping?  Or are you expecting some type of fault being
generated here?  There is also an interesting question on if the wrap around
is on the sender sequence number or on the partial IV.

* Section 6.1 - Based on what you are saving, do think that the following
attack might be doable.
1. Force the server to reboot
2. Send captured replay message #1 to the server.  Server should ignore it
3. Send captured replay message #2 to the server.  The server would reply
with a new payload and the same IV in this case?   (based on reflected IV
usage.) 
I don't think this is doable for regular OSCORE because the PIV is part of
the saved info.  And the use of echo prevents this attack from happening.
(A predictable echo value with reuse would be bad news here.)

* Section 7 /any of the/either of the/

* Section 8 - /and thus cannot be retransmitted/and thus are not
retransmitted/

* Section 8.1.1 - did we ever make a decision about the requirement to cache
the original kid context as well as the kid for observations?

* Section 8.3 - The second paragraph about resetting (or not resetting) the
sender id is confusing me.  I am not sure what I think I am resetting it
from and to.

* Section 8.4 - I am totally at sea about why you don't want to reset the
PIV when the context is reset.  Nod doing so is going to make detection of
roll over more difficult as I do it when it goes back to 0 not when it goes
back to where it was when the current security context is established.

* Section 9 - what is intermediary verification?  Third party?  This is not
group OSCORE so why should it?

* Section 9 - para 3 - I don't understand why this is a MUST implement.  Is
there a technical reason I cannot support block-wise transfer and do it with
the group-comm context rather than pair-wise?  Does this imply that the use
of an algorithm such as Walnut DSA imply that a group can never do echo
requests (and thus makes it harder to sync state) or transfer large items
because this algorithm cannot do key agreement.

* Section E.2 - I am wondering if there should be a warning about possible
reuse of an IV here.

Jim