Re: [core] Review of draft-ietf-core-oscore-groupcomm-07

[Marco Tiloca <[e-mail]>]

Hi Christian,

Thank you very much for your review!

We have addressed most of your comments in version -08 [1] submitted today.

Some points are still open and will be raised at the upcoming meeting on
Wednesday.

Please, find some replies inline.

Best,
/Marco

[1] https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-08

On 2020-03-27 18:15, Christian Amsüss wrote:
> Hello gropucomm authors,
>
> (I'll try to skip issues Jim already found)
>
> * Silent server: I don't see why the role as a client is described as
>   independent of being a silent server; doesn't the role as a client
>   automatically give it a sender context that that can be used in server
>   role just as well?

==>MT
We have expanded the definition of “silent server” in Section 1.1.

If the endpoint implements only the role of silent server, it does not
have a sender context (at least in signature mode) and expects to
process only incoming requests. That’s explained later on, but we can
anticipate it already here in Section 1.1.

Instead, if the endpoint implements only the role of client, then it has
a sender context and it is prepared to have multiple recipient contexts,
but it expects to process only outgoing requests and incoming responses.
<==

>
>   Would a proxy (say, one that serves a remote client accessing a local
>   multicast group) that verifies the client's legitimacy based on its
>   signature as a group member classify as a "silent server", and if so,
>   wouldn't "silent member" be more fitting?
>
>   ("Bonus question": Can such a proxy be provisioned with the public key
>   of the client but not the group key material?)

==>MT
Good points. This is related to a comment from Jim [1] about the key
management documents in ACE. The idea would be to have a “proxy
signature checker” as an entity which is not an actual member of the
OSCORE group.

That is, it needs to get the right permission to retrieve the public
keys of group members from the Group Manager, but it does not need to be
an actual group member and be able to retrieve the symmetric group
keying material.

While this is going to be defined in draft-ietf-ace-key-groupcomm and
draft-ietf-ace-key-groupcomm-oscore , we have now added a new paragraph
about this at the end of Section 2.3 of this document.

[1] https://mailarchive.ietf.org/arch/msg/ace/6YCtkE93HPajYcWrPlpxYxr8GkE/
<==

>
> * At some point in reading this, it would be comforting to be ensured
>   that however the keys are provisioned, I don't need to provision every
>   member with every other member's keys. (Eg. in a bipartite setup of
>   clients and servers, clients only need recipient contexts of servers
>   and vice versa). The line that does this now is "from which messages
>   are received" -- is that visible enough?

==>MT
Correct. Master Secret, Master Salt and ID Context are provisioned for
the whole group. The symmetric Sender/Recipient keys are derived when
needed.

In Section 2, we have expanded the text for the bullet point about the
recipient context.
<==

>
> * 2.5: OSCORE terminology on sequence numbers has so far not used
>   "wrapping" semantics, and only spoke of integers -- that those tend to
>   wrap is a programming language specific thing, and especially in the
>   typical 40-bit space is rarely the default. I could have sworn the
>   OSCORE document talks of sequence number "exhaustion", but it doesn't;
>   either way, "An endpoint can eventually exhaust its own ..." might be
>   a better wording. (If wrapping needs to be mentioned, I think it
>   should rather be in "If an implementation's integers only support
>   wrapping addition, the implementation MUST detect a wrap and treat the
>   context as exhausted instead.")
>
>   (Also in 10.11)

==>MT
Thanks, we have rephrased Sections 2.5 and 10.11 to talk about
exhaustion, with wrap-around as a specific case to handle as and be
treated as exhaustion.
<==

>
> * 3.: I'd appreciate a reference to static-static diffie-hellman shared
>   secrets.

==>MT
We have added the following document as reference. Static-static
Diffie-Hellman is discussed in its Section 6.3.

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf
<==

>
> * general (but in particular 4.2, and "That Sender ID is valid only
>   within that group, and is unique within the group"): This all works
>   under the assumption that kid and kid-context are used in a
>   hierarchical way of kid residing "under" the kid-context, and that the
>   GM may assign any kid to a given node because the GM is in control of
>   the whole kid-context. This is not true if the client is also using
>   RFC8631 B.2 mode -- then, it needs to reserve some kid across all
>   kid-context. (It'd be tempting to partition those by whether a
>   multicast address is involved a request, but the Echo recovery happens
>   on unicast even when using group OSCORE).
>
>   It might be that this requires some adaptation in the way B.2 is used
>   in applications (eg. that they make their ID1 always start with some
>   agreed-on prefix that the group manager will not use).

==>MT
Yes, we build on the hierarchical assumption where ‘kid’ is under
‘kid-kontext’.

Now the Group Manager is the only entity in control of assignment and
decommission of IDs, so group members cannot just negotiate new IDs with
each other, but rather go back to the Group Manager if need be.

We have clarified this by expanding the current third paragraph in
Section 2.3.

If we want to open to RFC8613 B.2 mode as an alternative, reservations
and adaptations sound like indeed required. Then we have the problem of
keep ensuring uniqueness of kid values in the same group.
<==

>
> * 4.3.2: Why does theo Signing AAD need to cover OSCORE_option? 
>
>   <del>Things in the option that could be manipulated are the flags
>   (pairwise selects a different key), kid and kid context (which select
>   different keys) and partial IV changes the nonce -- of those, only the
>   Partial IV change would make the signature check succeed, and even
>   then, the AEAD will fail.
>
>   If it's only about the Partial IV and actually necessary, a bstr that
>   only encodes the PartialIV instead of OSCORE_option would make it
>   easier to obtain bounds for the size of the aad_array
>   serialization.</del>

==>MT
As you point out below, that started by considering what is now
described in Section 10.6.

A first proposal was to have the OSCORE option of class I altogether,
but that was not ideal for implementors.

We thought of including individual pieces of information from the OSCORE
option as elements of the aad_array in Section 4.3.2, but that risked to
complicate the description.

All in all, and considering that the AAD does not go on the wire, we
opted for including the whole OSCORE option in the aad_array.
<==

>
>   *grml*, section 10.6 talks about that. I suppose that *does* require
>   that the AAD can be long enough to contain the longest possible OSCORE
>   option.

==>MT
Right, we have added this as further note for implementation in Section
4.3.2.
<==

>
> * 5.: I have the impression this means to say that in pairwise mode, the
>   payload is as in RFC8613 and not as in the first bullet, but doesn't.

==>MT
Correct. In the first bullet point, we have clarified in which modes the
signature is added.
<==

>
> * general (manifests in 5.1): It'd help understanding the structure if
>   there was a note around the ciphertext saying that this is a 28 byte
>   ciphertext created from a, say, 12 byte request and including a
>   16 byte tag.

==>MT
We have extended the text introducing the examples.
<==

>
> * 7.1.1 and later observation handling: Does letting observations run
>   through a re-keying open us up to the risk that the client could
>   receive the same KID again, start its sequence numbers anew, sends out
>   a different observation on the same (KID, PIV) pair (but a different
>   key) and the responses get mixed up?
>
>   (Maybe observations just need to terminate on rekeying, like they do
>   when your IP addresses change?)

==>MT
Terminating observations across rekeying would be pretty inconvenient.
In applications requiring backward/forward security, each (burst of)
joining/leaving would trigger a rekeying, with consequent termination of
all ongoing observations.

The client and all the group members should actually maintain the same
‘kid’, as the Group Manager should not change them when rekeying the group.

However, the above is assuming that the Sender Sequence Numbers reset
upon group rekeying. We never say it explicitly but the intention was to
rather keep the Sender Sequence Numbers growing, which also helps
observations to stay alive across group rekeyings.

So this is also about clarifying if Sender Sequence Numbers should be
either reset to 0 or not after a group rekeying. Both approaches have
pros and cons.
<==

>
> * 7.2 (and 7.4): Is there any prescribed order between counter signature
>   and AEAD verification? With the caveats of the below 9.1.1 comments,
>   can the client forego verifying the AEAD tag if it verifies the
>   signature first?

==>MT
This was discussed for previous versions of the draft. The conclusion
was to not mandate any particular order, so being flexible as long as
both the signature and the tag are checked.
<==

>
> * 7.3: The same concerns as in 7.1.1 apply here where the different
>   security contexts are used in request and response.
>
>   Especially, why is the SHOULD on taking a new partial IV not a MUST?
>   After all, the use of the original Partial IV is scoped over the Key
>   IDs, and using the requester Partial IV in the new security context
>   both for answering requests from this and from the old securty context
>   (and thus, the old kid space) is inviting nonce reuse.
>
>   My current impression is that in well-thought-through applications,
>   the late updates can work well enough even in constrained applications
>   to not take the risks of crossing contexts between requests and
>   responses.

==>MT
We have made it a MUST.
<==

>
> * 9.1.1: I had a lot of text here but found that Jim already said it
>   better. If found to be secure, this at least needs concrete guidance
>   of which stream cipher to use to replace which AEAD algorithm.
>
> * 10.5 or wherever that fits: The namespacing considerations we've
>   recently rolled in the OCF call might apply here as well. Unlike in
>   non-group OSCORE where the recipient is the authority of its recipient
>   IDs and can shard them as it pleases, in a group the group authority
>   (whoever allowed taking that group IP address) can shard the group IDs
>   between different GMs that manage groups on the same address, if such
>   a thing does at all make sense to deploy.
>
>   (I placed this on "or wherever that fits" because while what's said in
>   10.5 is true on the security side, I'd very much like things to be
>   designed that way that devices don't ever need to try multiple
>   decryptions. One practical reason is that decryption can often be done
>   in-place, but libraries don't promise to keep the old ciphertext
>   intact when decryption fails).

==>MT
We have added the current third paragraph in Section 10.5 following your
suggestions. We have also added related privacy considerations, in the
current last paragraph of Section 10.15.
<==

>
> * Counter Signature Parameters Registry and following: Given how tightly
>   this is tied into the COSE registry, has it been considered to make
>   this an extension there? This would increase visibility of the
>   parameters registry to those who enter new counter signature
>   algorithms into COSE, and encourage them to describe the parameters
>   right away.

==>MT
We plan to remove the IANA registries in Section 11.1 and 11.2, and
rather point at the updated COSE registries at
https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-algs-07
<==

>
> * The 'encoded as specified in the "Parameters" field' of 4.3.{1,2} and
>   the parameters description of 11.2 miss some glue to me. I suppose
>   that the parameters field is a CDDL expression, which would be such
>   glue (ie. an EdDSA with kty=1 and crv=2 would be encoded as CBOR `[1,
>   2]`), but that is not explicit.

==>MT
Correct, and to be revised when pointing directly at the updated COSE
registries.
<==

>
> * 11.3: For the assignment of OSCORE Flag Bit 2: Is this only used for
>   group OSCORE, or can this be usd in other situations where both parties have
>   (or can have) static-static keys?

==>MT
Good question. So far, we have thought of Group OSCORE only, we don't
see a more general meaning.
<==

>
>   If it is particular to group OSCORE, it might make sense to leave its
>   meaning in non-group-OSCORE setups undefined. (A kid/kid-context
>   combination needs to be recognized as a group or non-group key with
>   either value, so the remaining value is free for non-group
>   applications). In that light, flipping the bit's value might be
>   worth considering, as "pair-wise mode" is the default for non-group
>   OSCORE. (AFAIR there was a "has counter-signature" bit in earlier
>   drafts. Why was that changed, just because "0" is the more natural
>   default value in group OSCORE?)

==>MT
Flipping the value makes sense.

So the bit can be 0 for symmetric-protected messages (in OSCORE; in
Group OSCORE in pairwise mode), or 1 otherwise (in Group OSCORE
signature mode).
<==

>
> * E.2: This is basically a trust (freshness) on first use -- but why is
>   the first use discarded? An attacker can send in two consecutive
>   requests just as well as one, so the server could relay the first
>   request to the application just as well.

==>MT
Right. We have changed it to not discard the first message.
<==

>
> * Appendix E in general: As I understand, sending a Partial IV in the
>   "Protecting the Response" step is as optional as in regular OSCORE:
>   you can do it, and need to under some circumstances, but for
>   efficiency you don't unless you need to.

==>MT
Correct.
<==

>
>   If that is the case, E.1 and E.2 should be explicit about that while
>   they may be good enough for the application's freshness requirements,
>   they are not good enough for using the request's Partial IV, at least
>   if the baseline synchronization state can ever get lost.

==>MT
Correct, this is now explicitly discussed in both E.1 and E.2.
<==

>
> * E.3: That unicast repeated request 
>
>   "otherwise, the request is silently discarded": Why? This could just
>   be due to a client that has taken its time, I'd have expected
>   "otherwise, a 4.01 (Unauthorized) including an Echo option is sent as
>   above".

==>MT
Right, we have updated the text to send a 4.01 response with an Echo option.

Since the request including the Echo option is unicast, this was an
excessive adherence to the text in Section 7: "... it is RECOMMENDED
that the recipient does not send back any error message. This prevents
servers from replying with multiple error messages to a client sending a
group request, so avoiding the risk of flooding and possibly congesting
the group."
<==

>
>   And does the server need a time interval here? I'd implement Echo as a
>   random-per-bootup (or taken-from-own-sequence-numbers) source, and
>   don't see a cryptographic reason to concern myself with time there.
>   All that matters is that the new request is one the client sent after
>   my server came up, so it can't have been responded to in an earlier
>   life.

==>MT
Correct, we have updated the text for not caring about a time interval.
<==

>
>   I disagree with the "all group members [need to] understand the
>   elective Echo option" approach; Echo is defined as elective, and
>   unknown Echo values can be ignored. Last but not least, two servers
>   could easily arrive at the same  Echo value. Using pairwise security
>   contexts would be much more suitable for the re-request, and not rely
>   on ignoring messages on mismatching Echo values, and should always be
>   used with this mode; see discussion at
>   https://github.com/core-wg/oscore-groupcomm/issues/26.

==>MT
We have removed that expectations from servers in the group, and
stressed that using the pairwise mode would solve the problem altogether.
<==

>
> * Appendix G: "Senders MUST NOT use [pairwise with] multiple
>   recipients": I was confused at first as to why this is not a "can
>   not", and only later realized this is to keep clients that want to
>   address a single server from just broadcasting a request with
>   pairwise encryption. This could be clearer.

==>MT
We have clarified this point in the third paragraph.
<==

>
> * G.1: The mechanism for address discovery is an odd mixture of
>   vagueness and concreteness. Suggestion to replace the three last
>   paragraph and its bullets: "To make this information available,
>   servers MAY provide a resource to which a client can send a request
>   for a server identified by its sender ID, or a set thereof. Details of
>   such an interface are out of scope for this document."

==>MT
Thanks, we have adopted your suggested text. Also, the “set thereof” may
also be the empty set. This would point at all the servers, in case the
client knows neither their addresses nor their ‘kid’ values.
<==

>
> * G, "Note that no changes are made to the AEAD nonce and AAD.": I'll
>   need to think this through again when implementing it.

==>MT
Ok.
<==

>
> Over all, a thing I'm looking forward to implementing in aiocoap.
>
> Kind regards
> Christian
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: [phone]
https://www.ri.se