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

[Jim Schaad <[e-mail]>]

-----Original Message-----
From: Marco Tiloca <[e-mail]> 
Sent: Monday, April 6, 2020 10:32 AM
To: Jim Schaad <[e-mail]>; [e-mail]
Cc: 'CoRE WG' <[e-mail]>
Subject: Re: Review of draft-ietf-core-oscore-groupcomm-07

Hi Jim,

Version -08 [1] submitted today addresses most of your comments.

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

Please, find some replies inline. Thanks again for your comments!

Best,
/Marco

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

On 2020-03-26 19:20, Jim Schaad wrote:
>
> -----Original Message-----
> From: Marco Tiloca <[e-mail]>
> Sent: Wednesday, March 25, 2020 11:47 AM
> To: Jim Schaad <[e-mail]>; 
> [e-mail]
> Cc: 'CoRE WG' <[e-mail]>
> Subject: Re: Review of draft-ietf-core-oscore-groupcomm-07
>
> Hi Jim,
>
> Thank you for this review!
>
> Please, see inline some replies and requests for clarification.
>
> Best,
> /Marco
>
> On 2020-03-17 21:39, Jim Schaad wrote:
>> * Introduction - para 4 - I think you need to expand some text in 
>> this section to explain why it is that doing a pairwise response is still going
>> to be considered to be group communication.   This assumes some intimate
>> details of how multicast works in CoRE that might not be generally known.
> ==>MT
> Yes, we can expand. A response is sent unicast either way. The difference is that the pairwise-secure response remains confidential between the originator server and the recipient client.
> <==
>
> [JLS]  Yes, but in the case of block-wise, the following request might also be sent unicast using the same context as well.  This means that both requests and responses are done using this.  Thus you have taken multi-cast into unicast.

==>MT
Clarified in the current fourth and fifth paragraphs of Section 1.
<==
[JLS] Looks good

>
>> * Section 1.1. - Silent Server:  Consider adding the following to the 
>> definition "Given that for CoAP group communications, messages are 
>> normally sent without requesting a confirmation the idea of a server 
>> silently acting on a message is not unreasonable."
> ==>MT
> Good input, will do.
> <==

==>MT
Done.
<==
]JLS] Looks good

>> * Section 2.4 - para #3 - The implications of the paragraph are 
>> horrendous in terms of performance of the system.  It basically says 
>> that you need to do some excess processing in order to deal with this 
>> issue following a key roll-over.  If the first message received 
>> cannot be validated by the signature then there is an issue of the 
>> question was the message corrupted or was the id assigned to a new 
>> entity and thus a new public key is required to be pulled down.
> ==>MT
> If we understand correctly, the reason leading to this is the Group Manager re-assigning a dismissed Sender ID, e.g. to a new group member.
> As a consequence, the server will be able to retrieve an old Recipient Context matching that Sender ID, but then failing the message verification as not considering the correct public key. Then the issue you mention comes up.
>
> If this is correct, it’s probably worth adding some text like: i) the Group Manager should not recycle Sender IDs, especially in the short term; and ii) it’s up to application policies on the servers to check at the Group Manager that they have the correct public key for a given Sender ID, after a number of consecutive failed verifications.
> <==
>
> [JLS] Yes that would be an appropriate set of text to alleviate the issue.

==>MT
Added the current fourth paragraph describing mitigation policies.
<==
[JLS] Looks good

>> * Section 3 - are all of these pairwise keys to be tossed away when 
>> new keys are issued for the group?
> ==>MT
> Yes, because new Sender/Recipient keys are derived from the new group keying material, and then used in the HKDF to derive the pairwise keys.
>
> Note that the same shared secret can be preserved across rekeyings.
> Also, pairwise keys would not need to be recomputed right after a rekeying, but latest upon message reception, as their derivation is lightweight. We will clarify these points.
> <==
> [JLS] Not sure that I think that doing a pairwise key agreement is necessarily lightweight or that it is necessarily a good idea to keep the computed shared secret in memory after it is needed.  Might not be quite as lightweight as you think.

==>MT
Added text in Section 3.1 about discarding pairwise keys after a group rekeying and deriving a new ones.

On the shared secret, new text has been added about the fact that it does not change across group rekeyings, while not explicitly saying that it can be stored rather than computed again.
<==
[JLS] It should mostly be a new security consideration that keeping this secret around long term is a potential issue where, if it is leaked, then an attacker can do impersonation as long as they are in the group.  This may be an issue because the private key could be protected at a significantly higher level than generic memory is.  For example in a TPM.

>
>> * Section 3 - clarity is needed on how PIV is going to work for this.  
>> I would assume that it amounts to a separate context but this is not 
>> completely clear from the text.
> ==>MT
> Our idea was to have a single PIV per sender, used for all its outgoing messages, regardless the exact mode to protect each of them. We will make it clearer in the text.
>
> As a side consideration also to add, this PIV may jump forward more often, hence replay checks may be invoked more often on the recipient side. To better handle it, larger replay windows should be considered.
>
> Bottom line, this is due to the fact that not all recipients receive all messages from a given sender, i.e. the messages over multicast are addressed to the whole group, while the unicast messages (in signature or pairwise mode) are not.
> <==

==>MT
Added a new Section 3.2 clarifying that a sender endpoint has a single Sequence Number space, to use for all its outgoing messages regardless of the mode used to protect them.
<==
[JLS] Looks to be all there

>> * Section 7. - Para 2 - I have a problem with the second sentence.  I 
>> think that you need to make it clear who is supposed to be doing this 
>> retransmission.  It should not be the CoAP system, but it is instead 
>> the application.  That means that a new request could be sent rather 
>> than a retransmission occurring.
> ==>MT
> Ok, we'll clarify.
> <==

==>MT
We have clarified that retransmissions are handled by the application for group requests over multicast as Non-Confirmable.
<==
[JLS] Look good

>
>> * Section 7.1 - Does not reflect the case where pairwise is used.   Ditto
>> for other sections. - found it in section 8, but that does not seem 
>> to be referenced from section 9 which is "message processing".
> ==>MT
> In this section, we can clarify that the text refers to the Signature mode. Would it be ok?
>
> The pairwise mode is later described in Appendix G.
> <==
> [JLS] Yes, that is a fine approach.

==>MT
The beginning of Section 7 clarifies that its text refers to the signature mode.
<==
[JLS] Look good

>
>> * Section 7.4.1 - Must send the group identifier on the first observe 
>> following a rekey operation to all clients.  ---- I am not sure that 
>> the group may not be required at all times - We need to discuss why you think
>> this would not be true.   Think of the case of two different observe
>> relations from the client to the same server sent using the same pair 
>> of ports on both devices but with different groups.
> ==>MT
> This comment seems to actually refer to Section 7.3.1, third paragraph.
>
> Probably the best compromise here is saying that a server MAY include the Gid in many or all notifications after rekeying, e.g. if identifiers are reused in different groups. This would trade off the message overhead with the chance of collision. Would it be ok?
> <==
> [JLS] There are two cases:  1) after the rekey and 2) two security groups on the same multicast address (or unicast addresses in the case of pair-wise)  I still need to look at the second case as it may be dealt with by message id.  I am just not sure.
>
>> * Section 9 - I thought I understood how this is going to work and 
>> after reading this I find that I am wrong.  I am almost positive that 
>> I dislike the compression for sending a request.
> ==>MT
> See reply below. Note that the part on optimized responses should be fine, as identical in the pairwise mode of Appendix G.
> <==
>
>> * Section 9.1.1 - I believe that this is just wrong - I would have 
>> thought that this is keep the tag and omit the countersignature.  As 
>> written you have messed up the AEAD and thus one level of security on this.
> ==>MT
> Could you be more specific on the problem this creates? SIGMA-I and IKE also consider a MAC not sent but included under a signature.
>
> Your original interpretation (keep the tag and omit the signature) is the case of requests in the pairwise mode of Appendix G.
> <==
> [JLS] There are a couple of different issues that I have for this: 
> 1.  I now need a new mode for my AEAD algorithm where it will provide output without validating that the MAC is correct.  I do not know if this is doable with any of my current crypto libraries.
> 2.  It permits for one to create a situation where the same encrypted value could potentially be decrypted into two different plain texts by the use of different keys or IV values.  It requires a security analysis to ensure that this is not possible, for example in the case where a sender incorrectly derived the key and base IV.
>
>> * Section 10.1 - should deal with the bilateral version and say that 
>> it does not follow these rules.
> ==>MT
> We can surely add considerations about the pairwise mode of Appendix G.
> In particular, since the pairwise mode uses symmetric keys to protect messages, it does provide pairwise confidentiality and source authentication without signatures.
> <==

==>MT
Added a paragraph discussing how this changes when using the pairwise mode.
<==
[JLS] Looks fine.

>> * Section 10.7 has interesting block-wise implications that need to 
>> be explored.
> ==>MT
> Could you elaborate more on this point?
>
> Does this “just” mean that the attack has an even more severe impact when involving the transfer of big bodies with blockwise? Or is it about something more, such as mixing-up the blocks of two different but “akin”
> blockwise transfers to two different target servers?
>
> Should we even recommend against using the signature-mode for any unicast request using block-wise, i.e. not only for non-safe methods such as PUT, POST and PATCH/iPATCH?
> <==
>
> The first paragraph says that using group OSCORE is bad when done over unicast, but if you do blockwise transfers and don't support the pairwise situation then this is exactly what you are going to be doing.  I don't know if this means that the pairwise needs to be upgraded to a mandatory to implement or if the NOT RECOMMENDED is too strong of a statement for this situation.  The same problem occur with use of the ECHO option as the response to the ECHO needs to be unicast not multicast (it only applies to a single server) and thus falls into this same category.

==>MT
Added the current fourth paragraph discussing how the attack affects block-wise transfers.
<==
[JLS] I think this covers my issue.

>
> Jim
>
>
>>
>>
> --
> 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
>
>
>

--
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