[core] FW: Review on draft-ietf-core-oscore-groupcomm-03

Jim Schaad <ietf@augustcellars.com> Wed, 09 January 2019 15:10 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A171277D2 for <core@ietfa.amsl.com>; Wed, 9 Jan 2019 07:10:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKbysNvzbPB3 for <core@ietfa.amsl.com>; Wed, 9 Jan 2019 07:10:11 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8361A124BE5 for <core@ietf.org>; Wed, 9 Jan 2019 07:10:10 -0800 (PST)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 9 Jan 2019 07:10:04 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: core@ietf.org
References:
In-Reply-To:
Date: Wed, 09 Jan 2019 07:10:01 -0800
Message-ID: <001201d4a82d$65ec80e0$31c582a0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdSnyYbiZGiVP8UBR0m/WlSp6oHGzAAY9OSg
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/kx3ePNG3RbxtoFC9pZnYKggccew>
Subject: [core] FW: Review on draft-ietf-core-oscore-groupcomm-03
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2019 15:10:18 -0000

Send to the right mailing list.

-----Original Message-----
From: Jim Schaad <ietf@augustcellars.com> 
Sent: Tuesday, January 8, 2019 11:00 PM
To: 'draft-ietf-core-oscore-groupcomm@ietf.org'
<draft-ietf-core-oscore-groupcomm@ietf.org>
Cc: 'cose' <cose@ietf.org>
Subject: Review on draft-ietf-core-oscore-groupcomm-03

So I did a quick run through on this document with the intention of starting
an implementation.  During this process I came across the following issues:

* There should be a note someplace in the document to the effect that if a
new group id is generated, then there must be no reliance on the kid for an
entity being the same.  This can only be done by looking at the signing
public key.   Also if an entity gets to the point of nearing a roll-over,
then the Group Manager could just assign a new kid rather than re-keying the
entire group.

* Section 4.1 - Given that the signature is no longer part of the option
value, something that is both good and bad, I am unsure that there is any
requirement for the 'CounterSignature0' bit to be part of the bit array.
According to the requirements, one can always assume that for a group
message the counter signature will always be appended to the encrypted text.

* Section 3.  I am not clear if the group ID should be part of the aad_array
or not.  If it does not need to be present then I think that some text as to
why it does not need to be covered would be appreciated.  I should note that
I don't think that it needs to be there but have not proven it to my
satisfaction yet.

* Section 5 - The text says that Observe is not defined for group setting.
I am not sure that this is a true statement.  RFC 7641 does not say anything
one way or another about doing observer for multicast.  The only issue that
I can see is the fact that the path may not always be setup correctly if
going through a proxy, but for local network without a proxy I don't see any
reason why it should not work.

* Section 5.1 - I am unclear of why you are looking at talking about
re-transmission in this context.  This needs to be clarified.

* Section 6. - The fact that they are non-confirmable does not preclude
acknowledgement even in a group situation.  It may not be advised in general
but it is allowed.

* Section 6. - Note that responses can be confirmable even if the request is
not.

* Section 6.1 - You are missing the signature step here.

* Section 6.2 - I believe that there should be the ability to decouple the
processing of a response from the query back to the GM.  Specifically, if
you get a new kid for the group id, one should be able to ignore the current
message and start an async request for the new keying information on that
new sender.  Forbidding this should be an application decision not general
purpose.  Perhaps this should also include a note about the fact that a
server might observer the GM in order to get these new kids in a timely
manner.

*