Hi Hannes,
On 7/21/16 12:30 AM, Hannes Tschofenig wrote: > 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. +1. > >> >> (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. Somebody has to be first. Others should step forward. > >> >> (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. Yes, but this is not a reason to not adopt a document. It's a reason to have editors and chairs who can move the ball. What is a reason is the above and below. > >> >> (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. > Fair. Eliot
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
