Subject: [core] Review on draft-tiloca-core-multicast-oscoap-01

From: Jim Schaad <[email-masked]>
Date: Wed, 5 Apr 2017 18:58:54 -0700

Here are a few comments on this draft.

Section 1 - "Keying Material" - it is a bit confusing to say "key, key
pairs".   I suggest that this become more detailed on the types of keys -
and perhaps purpose - or maybe just reduce to one item.

Section 1 - "GM" - The sentence starting "A GMC can" should be split into
two as the concepts are different.

Section 1 - "GM" - I think that the word 'may' should not be in these
sentences.  This is what it is responsible for, a group may not use the
services.  That is a different statement.

Section 1 - "GM" - I do not understand what this sentence is trying to say
"Any message exchange with the GM MUST be secured and based on different
secure channels for different endpoints."

Section 1 - "Listener" - Are there cases where a listener may reply to a
multicast message w/ a multicast rather than a unicast message?

Section 1 - "Group response" - Is this a normal term?  Group is implying
multicast to my uneducated mind.

Section 1 - "Source authentication" - suggest the last sentence ends "not
tampered with either by a different group member or by a non-group member".
	
Section 2 - "Multicast communication technology" - The first for instance is
a problem, thisis really an M-to-N situation if you are talking about
"switches".  You should probably change this to "a single switch" so that it
is really 1 not M.

Section 2 - You should probably add a requirement on ordering of messages.
Specifically - there is a requirement that it is possible to determine
ordering of messages coming from a single sender, but it is not a
requirement to be able to determine the correct ordering of messages between
two different senders.  If this is a requirement then it needs to be
incorporated into the data portion of the protocol.

Section 3- para 3 - the last sentence needs to be cleaned up a bit.  It
could be read as saying that two endpoint ids that are in different groups
is precluded.

Section 3 - Note that endpoint ids only need to be assigned to multicasters,
a pure listener that never responds w/ unicast does not need to have an
endpoint id.  This would be protocol specific.

Section 4 - You would have zero or one sender context - depending on if you
would ever respond unicast to a message - protocol dependent.

Section 4 - You would have R recipient contexts.  One for every possible
sender of a message to this endpoint.  This would be M-1 or N-1 for a
multicaster (depending if unicast responses are needed) or M for a listener.

Section 4 - Creation of recipient contexts on demand is an optional item.
The current text reads as mandatory.

Section 4 - Need to update the last paragraph of this section to deal with
the changes in OSCOAP - I assume that Cid is converted into a Group
Identifier.  The question then becomes if this is transmitted as a separate
item or if it is part of the kid when transmitted.  Additionally, how it is
put into the AAD needs to be modified.

Section 5 - Yes - need to be sure to highlight the difference between this
and unicast as re-use of serial numbers might occur without the change of
using the sender context partial IV always.

Section 6.2 - The order of verifying the signature and doing the decryption
does not matter and thus should not be mandated.  It may be that it is
cheaper to do the decryption first as long as the memory constraint is not
so large that decryption in place is needed.  This would allow the cheaper
operation occur first.

Section 6.4 - the mapping rules are not necessarily the same in the final
paragraph of this section.  This is because of the updates to OSCOAP.

Section 7.3 - You need to have a bit of a discussion here about the
difference between a late joining endpoint and a new endpoint that is
joining an existing group.  The in latter case there would not be an issue
w/ serial numbers because a new context is going to be created.

RANT - Please review all 2119 language.  If it does not refer to a byte on
the wire or to a specific step that one of the parities is going to perform,
then it is not appropriate.  Example the MAY in the first paragraph of
section 3.   How would I even think about doing a compliance test for this?

Jim

---

From: "Beck, Stefan" <[email-masked]>
Date: Tue, 25 Apr 2017 12:54:46 +0000

Hi,
On Section 2:
Group-level data confidentiality and Source authentication are described as SHALL, while Message integrity is SHOULD.

Intuitively I would consider authentication and integrity as SHALL, while confidentiality could be seen as SHOULD (or even MAY? - as the following text already correctly suggests that data confidentiality may only be required if privacy sensitive data is exchanged - which is not necessarily the case, e.g. in simple situations

On authentication and integrity: I would use SHALL consistently here - similar to what is already written on "source authentication" in section 1. And it is implied by the last statement anyway ("Message integrity is provided through the same means used to provide source authentication.")

Section 7.1: the first paragraph addresses the confidentiality part of "Group-level Security", so you could potentially rename 7.1. to "Group-level Data Confidentiality" as one specific part of the security considerations (provided that this first paragraph remains the only one in 7.1...):
 - the second paragraph deals with the obvious ("it is required that all group members are trusted"), so it could even be removed completely?
 - and the 3rd paragraph would better fit to 7.2 IMO (as the task of removing a compromised group member becomes a key management task - similar to when legitimate - yet uncompromised - group members are leaving).

I also agree with Jim's proposal (on section 1, excerpt below), the same could be applied in section 2 (and 7.1) analogously.

Stevie

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Thursday, April 06, 2017 3:59 AM
To: [email-masked]
Cc: 'core' <[email-masked]>
Subject: [core] Review on draft-tiloca-core-multicast-oscoap-01

<...>

Section 1 - "Source authentication" - suggest the last sentence ends "not tampered with either by a different group member or by a non-group member".
	
<...>

Jim

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: "Beck, Stefan" <[email-masked]>
Date: Thu, 27 Apr 2017 20:50:33 +0000

Hi Marco,
Thanks for considering my comments.
With "simple situations" I meant payload data only, not signatures or MAC.
A sample use case could be group messages that switch on / off dozens or
more luminaires at once. There's no sensitive payload data involved here.
And even if encrypted one could easily find out what is going on, just by
monitoring network package flow.

Having said that, I fully agree with you though, that encryption should be
the norm anyway. I just stumbled over the use of SHALL, SHOULD and MAY in
those three last bullets of section 2, which is inconsistent IMO.
I would change as follows:
1. Group-level data confidentiality: messages sent within the multicast
group *SHOULD* be encrypted.
...
In particular, messages *SHALL* be encrypted if privacy sensitive data is
exchanged in the group. (or alternatively: describe the privacy concerns in
the Security Considerations section)

2. Source authentication: ok

3. Message integrity: messages sent within the multicast group *SHALL* be
integrity protected.

Stevie

-----Original Message-----
From: Marco Tiloca [mailto:[email-masked]] 
Sent: Thursday, April 27, 2017 6:25 PM
To: Beck, Stefan <[email-masked]>;
[email-masked]
Cc: 'core' <[email-masked]>
Subject: Re: [core] Review on draft-tiloca-core-multicast-oscoap-01

Hello Stefan,

Thanks a lot for your review and comments, we have been revising the draft
accordingly.

As to your comment:

"Intuitively I would consider authentication and integrity as SHALL, while
confidentiality could be seen as SHOULD (or even MAY? - as the following
text already correctly suggests that data confidentiality may only be
required if privacy sensitive data is exchanged - which is not necessarily
the case, e.g. in simple situations"

Do you refer to a signature or a MAC? Also, can you refer to any particular
case where confidentiality is not required?

Please, consider that group members do own the key material they need for
encryption anyway, and [1] suggests encryption as the norm and that newly
designed protocols should prefer encryption to cleartext operation.

Best regards,
/Marco

[1]
https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/

On 2017-04-25 14:54, Beck, Stefan wrote:
> Hi,
> On Section 2:
> Group-level data confidentiality and Source authentication are described
as SHALL, while Message integrity is SHOULD.
>
> Intuitively I would consider authentication and integrity as SHALL, 
> while confidentiality could be seen as SHOULD (or even MAY? - as the 
> following text already correctly suggests that data confidentiality 
> may only be required if privacy sensitive data is exchanged - which is 
> not necessarily the case, e.g. in simple situations
>
> On authentication and integrity: I would use SHALL consistently here - 
> similar to what is already written on "source authentication" in 
> section 1. And it is implied by the last statement anyway ("Message 
> integrity is provided through the same means used to provide source 
> authentication.")
>
> Section 7.1: the first paragraph addresses the confidentiality part of
"Group-level Security", so you could potentially rename 7.1. to "Group-level
Data Confidentiality" as one specific part of the security considerations
(provided that this first paragraph remains the only one in 7.1...):
>  - the second paragraph deals with the obvious ("it is required that all
group members are trusted"), so it could even be removed completely?
>  - and the 3rd paragraph would better fit to 7.2 IMO (as the task of
removing a compromised group member becomes a key management task - similar
to when legitimate - yet uncompromised - group members are leaving).
>
>
> I also agree with Jim's proposal (on section 1, excerpt below), the same
could be applied in section 2 (and 7.1) analogously.

--
Marco Tiloca, PhD
Research Institutes of Sweden
RISE ICT/SICS
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)
Phone: +46 (0)70 60 46 501
https://www.sics.se
https://www.sics.se/~marco/

The RISE institutes Innventia, SP and Swedish ICT have merged in order to
become a stronger research and innovation partner for businesses and
society.
SICS Swedish ICT AB, has now changed name to RISE SICS AB.