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

[Marco Tiloca <[e-mail]>]

Hello Jim,

Thank you very much for your comments!

We took them into account for the latest version -03.

Please, find our answers in line.

Best,
/Marco

On 8/29/18 4:09 AM, Jim Schaad wrote:
> Introduction - The use of DTLS will not work for the multicast send.  This
> should be noted

MT: Now we mention it in the last paragraph of the introduction.

> * Text on counter signature algorithm seems to be internally inconsistent.
> If a single algorithm is to be used, then it is dictated by the GM and as
> such there is not a list of algorithms which is part of the policy.  I am
> unsure if there is really a requirement for a single algorithm to be used
> here.  How much of a requirement on endpoints to maintain multiple signature
> algorithms during roll over al algorithms does this impose?

MT: We have clarified this point in Section 2, when discussing the
Common Security Context. A group member uses a single signature
algorithm, as dictated by the GM. Also, we now indicate ed25519 as
mandatory to implement.

>
> * Discuss the implications of rotating a new key over wrt message which
> might still be in transit or sent before the other EP learns of the key roll
> over.  How long do you keep the old context?

MT: This is discussed in the new Section 8.4 under the Security
Considerations. It is up to the application to define the maximum amount
of time an old context is possibly retained.

>
> * I don't want the size of q to be implicit - place make it explicit.  My
> code is decoding the header before I know what the context is and therefore
> what |q| is and don't want to parse it.

MT: We moved the countersignature away from the OSCORE Option. The
countersignature is now appended to the encrypted payload of the OSCORE
message.

MT: So doing: i) the message header can be parsed entirely; ii) the
OSCORE security context is retrieved; iii) the signature algorithm in
the Security Context indicates the size of the countersignature at the
end of the OSCORE message.

>
> * Not sure that I would want to use it, but what is the length of a hash
> based signature.

MT: they can be quite large in size, see also
https://tools.ietf.org/html/draft-mcgrew-hash-sigs-13

MT: since we moved the countersignature to the end of the OSCORE message
as per the comment above, there is no need to explicitly indicate its
size in the OSCORE option as before.

>
> * Section 4 - may be worthwhile to say that this does not prevent the
> acknowledgement of a CON request for non-multicast environments.

MT: We have mentioned it in the third paragraph of Section 6 (former
Section 4).

>
>
> * section 4 - does the prohibition on sending responses extend not only to
> malformed messages but to messages which do not validate cryptographically?

MT: Absolutely. Now the second paragraph of Section 6 (former Section 4)
also says "... or which is not cryptographically validated in a
successful way."

>
> * Section 7.2 - remind me what cases A and B are here

MT: Done (now Section 8.2).

>
> * What is the external_aad structure used for the counter signature
> operation - is it the same as for the encryption?

MT: Yes, it is the same one. Now we explicitly say that in Section 3,
first bullet.

>
> * Should make it explicit that the kid is always set in a response - unlike
> normal OSCORE.

MT: Now we say it explicitly in Section 3 (second bullet), as well as in
Section 4.1 (first bullet) when discussing the fourth least significant
bit of the flag byte.

>
> * Appendix A - the group size should note that the differences that are
> introduced by the use of silent servers - In that case the group size is
> limited by how stable it is and not the gross count of members.

MT: Could you please elaborate more on this point?

MT: "Stable" makes me think more of no or infrequent changes in the
group membership, regardless the role(s) of the group members.

MT: If the group size does not take into account silent servers (that by
the way can be configured also as clients), I agree there is a weaker
relation between group size and amount of expected traffic in the group.
On the other hand, it would badly reflect the expected overhead for
rekeying the group, which affects all members regardless their role(s),
hence why I tend to see the "group size" as a "gross count".

>
> * Notification from a client to the GM about the possibility of exhausting
> the PIV space

MT: This is now discussed in the new Section 2.2.

>
> * Appendix C - should note that roll over on the epoch w/o modifying the
> group prefix is perfectly reasonable assuming that sufficient time has
> elapsed so that the group ID is still temporally unique (i.e. there should
> be no messages running around the system w/ the old one).  Rate of
> addition/deletion of members can therefore be an influence on the size of
> the epoch.

MT: This is now discussed in the fifth paragraph of Appendix C.

>
> s/consistently with/consistent with/

MT: Done.


Thanks a lot again for your review!

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