[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. *
- [core] FW: Review on draft-ietf-core-oscore-group… Jim Schaad
- Re: [core] FW: Review on draft-ietf-core-oscore-g… Marco Tiloca