Hi Thomas, thanks for the response.
On 07/21/2016 12:05 AM, Thomas Hardjono wrote: > > Generally I'm in support of any efforts to secure multicast messaging for IoT > applications However, I have some concerns about the ACE WG: > > (a) Mixing authorization with key management: authorization and > key-management > are separate functions, so they need separate specs. This is probably a document management aspect and from a protocol point of view there are indeed certain areas where authorization can separated from the key distribution. For example, separating the aspect where permissions are granted to access a specific resource are separately from key distribution. > > > (b) Application-independent key management: a good key management protocol > should be deployable for a reasonably broad set of applications area > (including Consumer IoT and Industrial IoT). > > So while its useful to have a solution for lighting application, it remains > to > be seen if the solution works for other applications. We have been looking at other application domains outside lighting as well but so far what we have are several companies interested from the lighting community asking for a specification. If there are other use cases as well then I am sure the group is interested to hear about them. > > > (c) ACE WG work-pace: The ACE use-cases document took over a year to finish, > with numerous argumentative & boring emails (I'm not going to name names). > Sigh. If it takes over 1 year just to agree on use-cases, I can't imagine how > long it will take to complete an IoT secure multicast key management > protocol. > Double sigh. Yes, that's indeed a fair concern. I am also worried about the speed. > > > (d) Reinventing stuff: The IETF did have a secure multicast WG that produced > a lot of drafts and some RFCs, notably RFC 3740 and RFC3547 (RFC6407). > There's > product out there implementing these already. Re-using work sounds useful. > > There's also a draft in DICE on multicast for DTLS (not sure what happened to > it). The DTLS multipath was discontinued. Instead, the current approach is to work on an application layer layer multicast security solution. > > There is the Fluffy draft, but so far the ACE WG has not been very interested > in it. The group decided to go for an OAuth-based approach in ACE but there are certainly multicast security aspects in the Fluffy draft that should be explored IMHO. > > > (e) Re-chartering: Will the ACE WG need rechartering and how long. The ACE group needs to be re-chartered to work on low latency group communication security. Whether this happens at all depends on the outcome of this discussion. Ciao Hannes > > > > /thomas/ > > > > > ------------------------------------------ > > >>>> -----Original Message----- >>>> From: Ace [mailto:[email protected]] On Behalf Of Hannes Tschofenig >>>> Sent: Wednesday, July 20, 2016 6:07 AM >>>> To: [email protected] >>>> Subject: [Ace] Adoption of Low Latency Group Communication Security Work >>>> in >>>> ACE >>>> >>>> Hi all, >>>> >>>> at the ACE meeting today I asked the participants whether they are in >>>> favor >>>> of adding low latency group communication security work in the ACE group. >>>> >>>> 20 persons were in favor of doing the work. >>>> >>>> 5 people argued against doing this work. >>>> >>>> If you haven't been at the meeting please contribute your thoughts here on >>>> the list. If you believe you do not have enough information please also >>>> speak up. >>>> >>>> Ciao >>>> Hannes > > > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
