Re: [Ace] Summary of ACE Group Communication Security Discussion

[Michael Richardson <[e-mail]>]

see inline as well.

In the summary, it was unclear if I was against the symmetric method or not.
I will admit that I'm sitting on the fence here.  I would prefer not to have
a standardized symmetric method.

My preference would be to start running code that shows the price/performance
of asymmetric methods in a lighting context.  It would have to be done by a
sufficiently resourced group motivated to show positive results.

Michael StJohns <[e-mail]> wrote:
    >> Without a hat on, you can add my support to Abhinav's proposal.
    >> Perfect is ideal, but you often can not make any progress if you
    >> accept nothing less.  The security considerations section will have to
    >> be thorough.

    > Hi Kathleen et al -

    > To attain "rough consensus", RFC 7282 requires that "all issues be
    > addressed" even if not all issues are accommodated.  So far the basic
    > issues of "this is unsafe as a mechanism for 'securing' a control
    > protocol" or even "how the heck do we keep this off the broader
    > internet" have not been addressed.

    > I once again suggest that the lighting folk go off and write something
    > that they implement as a group, and bring it back to the IETF as an
    > informational "here's how we did it" document, rather than adopting
    > this as a WG item.  The ONLY thing that even argues for considering
    > symmetric key multicast (vice asymmetric key multicast) is the latency
    > claims for lighting.  I haven't yet heard of another use case with the
    > particular combination of cheapness and latency of lighting which would
    > suggest this particular combination is useful elsewhere.

I realize that this thread is months old: I haven't seen any newer
conversation, so I'll continue anyway.

I would concur with MSJ's view that having an informational draft might be a
way to let this work go forward, but I suggest instead the right track might
be experimental.

I'm less sure that I agree with the subsequent view that we can't adopt this
item until we have assurance; I'd say that asking for the issue to be
addressed as part of the adoption process is reasonable, and objecting at
WGLC if it has not been addressed is the right way.

I will say I'm scared that garage door actuators and doors and security
systems will be sold with "lighting" interfaces.  This same thing happened in
USB space: zillions of inappropriate USB devices were given HID designations
because the windows drivers were easier to write/get-signed.