Re: [Ace] Comments on draft-tiloca-ace-oscoap-joining

[Francesca Palombini <[e-mail]>]

Hi Jim,

I don't think that your statement is correct: as far as I understood the oscoap-joining document, the RS is the group manager, while in the pubsub document (even generalizing it and making a group communication profile as Carsten was suggesting) the entity that does group management is the AS2.

I consider these differences a reason to have separate documents, yes, they could be described in the same draft, but I don't see how that simplifies the specifications.

One more comment inline.

Thanks,
Francesca

> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]]
> Sent: den 20 oktober 2017 07:42
> To: [e-mail]; draft-palombini-ace-coap-
> [e-mail]
> Cc: [e-mail]
> Subject: Comments on draft-tiloca-ace-oscoap-joining
> 
> After the interim meeting, I read this document through in order to produce
> a review.  Instead you are going to get a meta-review.
> 
> I am having a hard to seeing why this document exists in its current form and
> it is not some type of simple profile of the pub-sub security draft.
> While I am not sure that this document is a sub-set of that document, it
> appears to be about 90-99% a sub set of that document.  Consider the
> following:
> 
> You have both the publisher and subscriber roles as in the pub-sub draft.
> 
> You have an entity which is doing key distribution in the system.  For the pub-
> sub draft this is AS2 for you it is the RS, but they are performing the exact
> same set of tasks.
> 

Yes, they are performing the same set of tasks on a high level, but they are using the ACE framework differently in practice. For example the publisher and subscriber acquire the keys without using the token.

> The pub-sub draft as and endpoint which holds the encrypted messages, in
> its place you are using the multi-cast UDP channel.  In both cases they are
> basically unprotected-untrusted entities to distribute the content message.
> The only difference is that in the pub-sub model the RS will also provide
> restricted access to publishing which is not enforceable here.
> 
> Both of these documents are missing what I would consider to be core
> pieces.
> The pub-sub document does initial key distribution, while this document
> does not.  Neither document does any discussion of how subsequent key
> distribution is done to deal with forward and backward security of messages.
>
> 
> This document probably needs to define a new relationship, which might be
> more generally used, to say - this URL is where you get the security
> information for this URL which is published in the directory - esp in the case
> of multi-cast address URLs in the resource directory.  You might also find that
> the correct answer is not to use a separate resource for each channel, but to
> allow for the use of URI path elements to define the security for a resource.
> 
> Jim
>