Subject: Re: [Ace] Call for adoption for draft-somaraju-ace-multicast-02

From: Jim Schaad <[email-masked]>
Date: Mon, 6 Mar 2017 17:55:43 -0800

After thinking about this for a long time, I will reluctantly state a
position.

I do not believe that the WG should adopt this document at least until such
a time as a version has been released which does a substantially better job
of restricting the scope of the problem to be solved.  If the WG then
decides to relax that scope so be it.

Jim

From: Ace [mailto:[email-masked]] On Behalf Of Kepeng Li
Sent: Thursday, February 23, 2017 1:48 AM
To: [email-masked]
Cc: Kathleen Moriarty <[email-masked]>; Hannes Tschofenig
<[email-masked]>
Subject: [Ace] Call for adoption for draft-somaraju-ace-multicast-02

Hello all,

This note begins a Call For Adoption for draft-somaraju-ace-multicast-02 [1]
to be adopted as an ACE working group item, and added in the charter. The
call ends on Mar 7, 2017.

Keep in mind that adoption of a document does not mean the document as-is is
ready for publication. It is merely acceptance of the document as a starting
point for what will be the final product of the ACE working group. The
working group is free to make changes to the document according to the
normal consensus process.
 
Please reply on this thread with expressions of support or opposition,
preferably with comments, regarding accepting this as a work item.

Thanks,
 
Kind Regards
Kepeng (ACE co-chair)

[1] https://datatracker.ietf.org/doc/draft-somaraju-ace-multicast/

---

From: peter van der Stok <[email-masked]>
Date: Tue, 07 Mar 2017 09:33:05 +0100

After reading Jim's statement, my position is a bit different.
Multicast security is severely needed.
Not making it a WG document augments the risk that the subject is frozen 
and no progress is made.
To guarantee progress, adoption seems to me the right way forward.

Peter

Jim Schaad schreef op 2017-03-07 02:55:
> I do not believe that the WG should adopt this document at least until
> such a time as a version has been released which does a substantially
> better job of restricting the scope of the problem to be solved.  If
> the WG then decides to relax that scope so be it.
> 
> Jim
> 
> FROM: Ace [mailto:[email-masked]] ON BEHALF OF Kepeng Li
> SENT: Thursday, February 23, 2017 1:48 AM
> TO: [email-masked]
> CC: Kathleen Moriarty <[email-masked]>; Hannes
> Tschofenig <[email-masked]>
> SUBJECT: [Ace] Call for adoption for draft-somaraju-ace-multicast-02
> 
> Hello all,
> 
> This note begins a Call For Adoption for
> draft-somaraju-ace-multicast-02 [1] to be adopted as an ACE working
> group item, and added in the charter. The call ends on Mar 7, 2017.
> 
> Keep in mind that adoption of a document does not mean the document
> as-is is ready for publication. It is merely acceptance of the
> document as a starting point for what will be the final product of the
> ACE working group. The working group is free to make changes to the
> document according to the normal consensus process.
> 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Eliot Lear <[email-masked]>
Date: Tue, 7 Mar 2017 09:38:12 +0100

+1.

On 3/7/17 9:33 AM, peter van der Stok wrote:
> Not making it a WG document augments the risk that the subject is
> frozen and no progress is made.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 7 Mar 2017 11:37:16 -0500

> the WG then decides to relax that scope so be it.

I also cannot support the adoption of this document.  After listening to 
the arguments about latency and cost and hearing assurances that the 
protocol could be restricted to limit the impact of symmetric key 
multicast for control, I spent another few days with the document and I 
don't see how that  (restrictions) would be possible.

I support the adoption of an asymmetric key multicast solution for IOT 
control.  I cannot support any version, including this one, of a 
symmetric key multicast control system.

As I've noted before, this  proposal and document are based on a highly 
constrained, and as far as I can tell somewhat unique, set of 
limitations related to cost and latency (e.g. lighting control 
systems).  Let me reiterate that I believe the small subset of folk that 
are dealing in this space should instead generate an informational 
"Here's how we do it" RFC rather than attempt to place this proposal on 
the standards track.

With respect to Peter and Elliot's +1s on adoption, yes we could use a 
multicast based control system, and no, a symmetric key multicast system 
does not have the characteristics needed for secure control.

Lastly, the latency requirement argues, or perhaps screams that this 
would be better handled at the L2 link layer rather than an IP based 
system.  Simply IP routing the packet in an IOT system could consume 
most of the 250ms that the lighting folk argue is the maximum acceptable 
latency from throwing the switch until the lights go on. The argument 
about multiple technologies mostly doesn't hold water (e.g. you could 
use a consistent framing inside the various bearer RF and hard link 
link-layer standards).

Mike

> *From:*Ace [mailto:[email-masked]] *On Behalf Of *Kepeng Li
> *Sent:* Thursday, February 23, 2017 1:48 AM
> *To:* [email-masked]
> *Cc:* Kathleen Moriarty <[email-masked]>; Hannes 
> *Subject:* [Ace] Call for adoption for draft-somaraju-ace-multicast-02
>
> Hello all,
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 7 Mar 2017 17:45:03 +0100

On 7 Mar 2017, at 02:55, Jim Schaad <[email-masked]> wrote:
> 
> After thinking about this for a long time, I will reluctantly state a position.
>  
> I do not believe that the WG should adopt this document at least until such a time as a version has been released which does a substantially better job of restricting the scope of the problem to be solved.  If the WG then decides to relax that scope so be it.

I believe this editorial issue is exactly the kind of thing the WG process is very good in fixing.

So I support adoption at this time; this is not a WGLC.

Grüße, Carsten

---

From: Derek Atkins <[email-masked]>
Date: Tue, 07 Mar 2017 12:23:20 -0500

Peter,

> To guarantee progress, adoption seems to me the right way forward.

Can you please define what you mean by "Multicast Security"?  Are you
just looking for Group Confidentiality?  Do you want Group Message
Integrity without Source Authentication?  Do you want Source
Authentication?  "multicast security" is too generic a term by itself
and as others have pointed out depending on which specific security
services you're talking about you will get a multitude of (potentially
conflicting) requirements.  For example, you cannot get source
authentication with a shared-key-only solution.

I recommend that, before adoption, an explicit set of requirements be
defined and inserted into the scope.

>> the WG then decides to relax that scope so be it.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 7 Mar 2017 20:13:46 +0100

Hi Derek

we discussed the requirements quite a bit in the group already and the
conclusion of the discussion was that we provide two solutions, one
based on symmetric keys and the other based on asymmetric keys.

The asymmetric key solution provides authentication of the individual
sender where the symmetric key solution demonstrates knowledge of the
group key.

Ciao
Hannes

---

From: Jim Schaad <[email-masked]>
Date: Tue, 7 Mar 2017 14:25:17 -0800

And of course, the asymmetric solution is not the one that is currently in
the document.

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Tuesday, March 7, 2017 11:14 AM
> To: Derek Atkins <[email-masked]>; peter van der Stok
> <[email-masked]>
> Cc: Jim Schaad <[email-masked]>; 'Kepeng Li' <kepeng.lkp@alibaba-
> inc.com>; [email-masked]; [email-masked]
> Subject: Re: [Ace] Call for adoption for draft-somaraju-ace-multicast-02
> 
> Hi Derek
> 
> conclusion of the discussion was that we provide two solutions, one based
> on symmetric keys and the other based on asymmetric keys.
> 
sender
> where the symmetric key solution demonstrates knowledge of the group
> key.
> 
> Ciao
> Hannes
> 
> 
> >>> I do not believe that the WG should adopt this document at least
> >>> until such a time as a version has been released which does a
> >>> substantially better job of restricting the scope of the problem to
> >>> be solved.  If the WG then decides to relax that scope so be it.
> >>>
> >>> Jim
> >
> > -derek
> >

---

From: Jim Schaad <[email-masked]>
Date: Tue, 7 Mar 2017 14:26:48 -0800

It might just take one more update for me to feel happy with this.  However,
an update of the document has not yet been forth coming since I asked for a
couple of different types of things for the security solutions and so forth.
I would hope that the authors are not waiting for the outcome of this
adoption call as a gating factor to produce such an update.

jim

> From: peter van der Stok [mailto:[email-masked]]
> Sent: Tuesday, March 7, 2017 12:33 AM
> To: Jim Schaad <[email-masked]>
> Cc: 'Kepeng Li' <[email-masked]>; [email-masked]