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

Michael Richardson <> Sat, 12 November 2016 22:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 269171294B4 for <>; Sat, 12 Nov 2016 14:11:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NROZG0IY7f1E for <>; Sat, 12 Nov 2016 14:11:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D358A126CD8 for <>; Sat, 12 Nov 2016 14:11:31 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTPS id 603E31F906; Sat, 12 Nov 2016 22:11:30 +0000 (UTC)
Received: by (Postfix, from userid 179) id F192F3285; Sat, 12 Nov 2016 17:11:27 -0500 (EST)
From: Michael Richardson <>
In-reply-to: <>
References: <> <> <> <>
Comments: In-reply-to Michael StJohns <> message dated "Mon, 26 Sep 2016 11:41:52 -0400."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Sun, 13 Nov 2016 07:11:27 +0900
Message-ID: <>
Archived-At: <>
Cc: Michael StJohns <>
Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 12 Nov 2016 22:11:33 -0000

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 <> 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.