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

Jim Schaad <ietf@augustcellars.com> Wed, 29 August 2018 02:09 UTC

From: Jim Schaad <ietf@augustcellars.com>
To: draft-ietf-core-oscore-groupcomm@ietf.org
CC: 'core' <core@ietf.org>
Date: Tue, 28 Aug 2018 19:09:08 -0700
Message-ID: <042401d43f3d$46e429e0$d4ac7da0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AdQ/PMLgsW6VI6ZDQZu8eag2KSBHaw==
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/4gj7S5kRy37U9_jRXvZXVnVrgP0>
Subject: [core] Review of draft-ietf-core-oscore-groupcomm-02
Precedence: list

Introduction - The use of DTLS will not work for the multicast send.  This
should be noted

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

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

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

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

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


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

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

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

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

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

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

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

s/consistently with/consistent with/

jim

[core] Review of draft-ietf-core-oscore-groupcomm… Jim Schaad
Re: [core] Review of draft-ietf-core-oscore-group… Marco Tiloca