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

["Beck, Stefan" <[e-mail]>]

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:[e-mail]] 
Sent: Thursday, April 27, 2017 6:25 PM
To: Beck, Stefan <[e-mail]>;
[e-mail]
Cc: 'core' <[e-mail]>
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.
>
> Stevie
>
>
> -----Original Message-----
> From: core [mailto:[e-mail]] On Behalf Of Jim Schaad
> Sent: Thursday, April 06, 2017 3:59 AM
> To: [e-mail]
> Cc: 'core' <[e-mail]>
> Subject: [core] Review on draft-tiloca-core-multicast-oscoap-01
>
> Here are a few comments on this draft.
>
> <...>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core

--
Marco Tiloca, PhD
Research Institutes of Sweden
RISE ICT/SICS
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)
Phone: [phone]
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.