Subject: [Ace] Meeting Minutes of the ACE Virtual Interim Meeting on 9th February

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 23 Feb 2017 10:22:34 +0100

Hi all,

apologies for the delay in distributing the meeting minutes. We ran into
a few problems. The proceeding webpage unfortunately does not list the
interim meeting and hence we cannot upload the minutes, and slides
there. We are working on it; in the meanwhile we are distributing them
via email instead.

We only recently managed to download the Webex meeting recording due to
login problems. In any case, here is the recording now:
http://www.tschofenig.priv.at/ACE_Interim_Meeting_2017Feb09.arf

(We hope to be able to make the recording available on the same webpage
as the minutes/slides.)

To view the recording created by Webex you have to unfortunately use a
dedicated player since Cisco uses a dedicated format.

Here is the link to the ARF viewer:
https://ietf.webex.com/client/T31L/nbr2player.msi

In any case, let us know if something is missing or incorrect.

Ciao
Hannes & Kepeng

ACE Virtual Interim Meeting on 9th February
===========================================

Participants:
  * Abhinav
  * Hannes
  * Mike StJohns
  * Mohammed
  * Kepeng
  * Kathleen
  * Mohit
  * Piotr
  * Renzo Navas
  * Rashid Sangi
  * Eliot Lear
  * Francesca
  * Goeran Selander
  * Sandeep
  * Michael Richardson

Minutes
-------

Kepeng started the meeting and shared the short agenda.

Abhinav goes through the presentation.

Goeran asked whether the solution will be using CWTs.

Abhinav says that this is the intention. However, at the time of writing
the CWT document wasn't ready yet.

Goeran: How is the access token provisioned? There is no need for the
sender to provision to the receivers?

Abhinav: Yes, that's correct

Kathleen: What is the scope of each of these scenarios? By scope I mean
which are Internet scale vs. local, or is there a mix?

Eliot: I think we need to handle this in the traditional way. What are
the threats we are trying we are address? What are the vulnerabilities
in the system? We have to capture, absent other mitigation, it may not
be possible to determine the source of the compromise.
You stated the best mitigation: the key is scoped and cannot be used to
work across different environments (lights and refrigerator). There has
to be traceability as well from an enterprise administration point of view.

Sandeep: This is used within an enterprise domain -- not on an Internet
scale.

Eliot: I think the scope is even more narrow. It is not enterprise
scope. It is a small number of luminaries, preferable of a site. If I as
an administrator I don't have to turn off the entire building but only a
single group.

Mike: I have been hearing this argument for a while and have been
wondering how we can make this property of the protocol.

Eliot: I could come up with something. You use a random identifier when
the group itself is provisioned.

Mike: We know how tiny the scope of this particular application. It is
weired that we don't know how to prevent the protocol from getting
outside the scope.

Eliot: This is a largely a multicast protocol. So, you can use multicast
scoping.

Abhinav: You are saying that we can put in the protocol to ensure that
door locks can never use this stuff.

Mike: I have seen various arguments on the mailing list like "we cannot
do this over BLE". An example, is to limit the group size.

Eliot: Are you looking for a hard-upper bound limit in the size of the
group?

Mike: I am worried that someone is using this protocol despite all the
warnings and the discussions. The worry is that you are using this for
control. It is difficult to differentiate to limit it to the lighting
sector. I am looking for a way to severely constraining the protocol.

Kathleen: Can we have the management key be asymmetric ?

Mike: In IPv4 it is easier to keep things on the local network. For IPv6
it is a bit harder.

Abhinav: Is it possible to restrict it in the IPv6 scope?

Kathleen: There are lots of examples of IETF protocols where we cannot
use encryption, for example DHCP.

Mike: I am having the protocol with authentication and integrity.

Abhinav continues the presentation and talks about crypto performance.

Discussion between Mike, Hannes and Abhinav about the possibility of
software updates for the lighting sector and the implications of
hardware crypto.

Mike argues that companies should spent more money on hardware.

Eliot: Why are we talking about cost?

Abhinav: Mike asked about those numbers before the meeting.

Abhinav talks about the latency.

Mike: Why hasn't this be done in the IEEE?

Eliot: There may be multiple link layer technologies involved.

Sandeep: The devices may be wireless and may be wired together as well.

Mike: Fair enough.

Kepeng: Besides the details do we have high level objections?

Mike: Anything that talks about the way how the keys are stored is
probably not useful since it is not a protocol aspect. So, take this
out. The rest is OK.

Mike: Attacking a single node should not give you more access than this
single node has.

Mike: This particular application has tight cost and latency
requirements.  I would prefer this not to be a working group item but if
it becomes one then it heads into the right direction.

Eliot: I like this to go forward.

Mike: Could you give me an example from another industry?

Eliot: I have seen similar requirements in the transportation function.

Mike: I hope they never use this for control.

Kepeng: I believe there is consensus in the group to adopt this
document. Hannes, Kathleen?

Hannes: This is also my understanding from the discussions so far.

Kathleen: I agree. We can find out later what the status of document
should be.

Kepeng: I will initiate a call for adoption on the list.