Minutes interim-2021-t2trg-02: Tue 18:00
minutes-interim-2021-t2trg-02-202110261800-01
| Meeting Minutes | Thing-to-Thing (t2trg) RG | |
|---|---|---|
| Date and time | 2021-10-26 15:00 | |
| Title | Minutes interim-2021-t2trg-02: Tue 18:00 | |
| State | Active | |
| Other versions | markdown | |
| Last updated | 2021-11-18 |
T2TRG virtual summary meeting
Time: Tuesday, October 26th, 2021, 15:00-17:00 UTC
Video: https://youtu.be/rm4H2UuClz0
Thing-to-Thing research group
Chairs:
- Ari Keränen
- Carsten Bormann
Intro, RG status, upcoming meetings and activities (Chairs)
Ari (AK) introduces the meeting.
RG Document status:
- RESTful Design: updated recently; improved terminology and added
details on affordances. Authors believe it's time to go towards
publication. Next steps: chair review and last call. If you haven't
looked at this recently, please have a look and send comments to the
list. - Edge & IoT: go for publication request this year, as well
-
Michael McCool (MMC): read two versions, not the latest; most of my
comments were small matters, ... -
Security Bootstrapping: more 2022ish
- Title now: "initial security setup"
- Eliot Lear (EL): Major revision?
- Mohit Sethi (MS, for the authors): Carsten suggested the term
"initial security setup"; also identify the players involved; next
version: identify initial assumptions and knowledge imparted during
setup
A Data-centric CoAP Transport (Cenk Gündogan) [15:17]
(20) fine-grained forwarding vs. privacy
(33) to port ICN implementation to CoAP
(38) future work: discovery proxy paths
AK: reusing a lot of existing CoAP functionality -- what is the impact
on implementation size
Cenk (CG): State management may be underspecified in RFC 7252; not much
more than all other the parts...
CG: E.g., distribute name information in RPL DoDAG
Carsten (CB): there's a large body of ICN research out there. What are
the next pieces of research you would start to borrow? Useful elements
for data centric CoAP?
CG: having data-centric deployment opens door for all the ICN work. Lots
of caching strategies that should be easy to apply here. We have almost
no memory in these devices so need some cache replacement strategy. Also
a few pub/sub schemes from ICN world that might be beneficial with loose
coupling. Caching something definitely that one can use and that is easy
to get.
CB: looking forward to more research on that!
Matter Security & Privacy for Security & Privacy Experts (Steve Hanna) [15:46]
Matter is for Smart Home. Talking about security and privacy today.
URL: https://buildwithmatter.com/
The Matter specs will be open for everyone once published in their 1.0
version; here today can get a sneak peek. Not allowed to present all
details of the draft standard.
Matter intended to be of widespread utility (hence the name). One of the
essential goals: simplify smart home and IoT products so that consumers
don't have to worry about that.
Security recognized as essential. Matter works on top of TCP and UDP,
and IPv6. Wi-Fi, Thread, BLE, Ethernet supported today; more coming. Can
automatically provision e.g. Wi-Fi credentials.
Open source approach based on existing work. Common protocol from device
to cloud with end to end security. Not just security, like DTLS, but
also data model for specific device types. Like light would have "on"
and "off" or "color of light". Zigbee already had set of common data
models that is being extended for Matter.
Designed to be low overhead implementation. Aiming for less than 128KB
RAM and less than 1MB of Flash. May seem like large here, but for the
world of IoT players these are "medium".
Has been barrier in the past: how consumers can make devices work
together. Setup experience different whether iPhone or Android, etc.
Light bulb should be able to work with any admin or control devices you
have (Apple home or Google Nest, etc.). Devices should be able to work
with multiple ecosystems at the same time.
Matter supports set of device types (slide 8); more planned to be added
later. Smart speakers, laptops, mobiles should be able to control the
devices.
Open source at Github (PCHIP). Code already available with Apache
2.0. Raspberry Pi as reference platform you can run the code on.
Timeline: specs available to CSA members today. Don't intend to release
spec publicly before SDK is ready. Want running code as proof that the
spec is good. First half of 2022 should have products ready for
certification.
Every device with Matter logo will be tested like Wi-Fi devices are
tested. You can create your own protos at home but they won't be
supported in consumer environment.
Don't think just security of device but also network, cloud, and
gateways. Using well tested crypto. Intend to be hallmark for Matter.
Ease of use drives design.
Matter systems designed to be resilient. Can't protect from all
infections so need to detect and recover. Post quantum crypto important
consideration. Need to be able to adapt to new development and threats.
Threat model for Matter covers all sorts of threats. From cloak and
dagger attackers to ex-lovers. Need to revoke devices e.g., from
temporarily trusted parties.
Also devices may have long lifecycles that need to be considered. Also
considering human factors. Severity of different kind of attacks
considered in the work.
Distributed Compliance Ledger, can check DAC (Device Attestation
Certificate) against that (attestation).
Introducing a device: Scan Device (QR_Code).
Device gets set of credentials and is then able to operate fully in home
as a secured and trusted device.
During commissioning, storing new set of credentials; similar to Local
Device ID.
Operational cert:
Fabric ID, NodeID: 64-bit IDs
Private key corresponding to operational cert. Info on who can do what
(change light, e.g.). Raising the bar over today's smart home security:
easy&flexible commissioning, device validation, can check validity of
certs via distributed compliance ledger, strong ID, secured unicast
(based on TLS 1.3).
Secured group communication with secure group key. No sender
authentication yet with that, but assurance of group membership and
possibility to revoke. Remote attestation as optional; can use root of
trust.
AK: what's on top of TCP/UDP?
Steve (SH): secure channel protocol based on Sigma handshake. Also group
communication based on symmetric key; AES-128 CBC. Different from others
used. Have whitepaper coming and also one on transport and communication
aspects later in the calendar year.
(CB: relaying Jabber) MS: thanks for the great overview. Question on
slide 23: is it correct that the private key is generated outside of
device?
SH: no, private key can be generated on the device. In fact it would be
here always made on device. Sometimes, due to manufacturing
difficulties, could be made outside and injected, but during operation
generated inside.
CB: discussed the whole aspect of ownership and scavenging; interesting
question when IoT device come part of home, installed in home;
interesting ownership transfer is the involuntary transfer. When whole
home changes.
SH: is considered but not entirely solved. Uses physical access and
requires resetting each device. Painful now but looking to solve better
in future.
Michael Richardson (MCR): thanks for good slides. Use sigma-like TLS?
Don't seem to have algo agility. Hoping the whitepaper explains how to
deal with that. Would be useful to understand what the plan is.
On involuntary; have doc on this and would like more discussion on this.
Henning Schulzrinne (Columbia U) has done some work on this and have
interesting solutions. Not sure if fit to small devices. A bunch of
things happening in academic commmunity. Maybe good place to engage
across the whole industry.
SH: thanks! will look into this. Algo agility is built in here.
(from Jabber) Juan-Carlos Zúñiga (JCZ): I see there are several Security
design considerations. Specifically for Privacy, are there any
considerations beyond the Secure IDs?
SH: yes, additional privacy key accross the fabric to encrypt all IDs.
For example node IDs are encrypted so that in same Wi-Fi network will
not be able to decrypt unless have the corresponding fabric key.
Whitepaper will have more on privacy topics.
Reports from WISHI and other activities (Chairs) [16:2x]
Two WISHI calls:
- SDF, expanding scope to relationship (not just hierarchical) and
instance information (beyond the class information); - SDF ↔ DTDL; e.g. SDF's SenML units vs. external ontologies;
W3C WoT update (Michael McCool) [16:31]
Michael McCool (MMC) gave quick overview of WoT; much more details and
hyperlinks in the slides.
Have published WoT 1.0; working on 1.1 now, targeting end of year. Now
in clean-up for final release. New spec on discovery; finding TDs.
Profile specs for limiting scope.
Recent activity: finished plugfest; one of activities was converting SDF
to Thing Models (TM); templates for TDs. Solving similar problem as SDF.
TDs are instance definitions whereas TMs are classes. A couple new
commercial applications; Takenaka have built system using WoT models for
smart buildings. Also startup that is spin-off from TUM; building IoT
dashboard.
Directory for metadata queries. Have few implementations. SPARQL
supported for powerful searches.
For touch-points with IETF: wanted to include JSONPath queries.
Unfortunately no RFC yet. Plan is to make JSONPath informative
experimental feature. Have one mandatory mechanism other than JSONPath.
Don't want to mandate SPARQL or XPATH. Will have one simple now.
CoRE-RD used as first contact mechanism. Having discussion on 28th on
signatures, etc. Also feature completeness between SDF and TMs.
Experimental ideas: ontologies for geospatial data. Needs to be
coordinated with other groups. Used for location of IoT devices.
Sometimes data static and sometimes dynamic.
Location of device vs. location of feature of interest being measured.
Looking at signatures. Want to sign TDs but they are large and need to
be modified. Existing mechanisms not quite powerful enough. Looking at
how we can adapt or extend what is out there. Have draft proposal for a
new thing but want to see if can use existing things. Also JSON-LD
signature proposal but that's based on RDF canonicalization. Trying to
avoid RDF processing.
Will be extending current charter for 6 months to start next one in
July. Have set of features for TD 2.0. Maybe make normative something
like the geospatial. Also looking at managing data itself. Now have
directory for metadata but maybe want a directory for data. IEEE,
queries of intervals.
CB: for JSONPath, will have WG meeting in 2 weeks. Any doc we could use
for limiting the first version of JSONPath for the features we need?
MMC: we need more examples for our directory document. Key thing we need
to support is keyword search and search over the "@type". Like "find all
lights". In two weeks time hopefully will have details.
CB: how about in 10 days?
MMC: can bring up tomorrow in f2f
CB: something preliminary would be very helpful
MMC: also owe a review of the draft and braindump of the minimum set.
OneDM update, iotschema (Michael Koster) [16:45]
Michael Koster (MJK) gave update on application semantics work we are
tracking: OneDM and iotschema.
SDF being developed at IETF ASDF WG. OneDM concensus process has been
developed. Niklas helped to do this. Have started to do reviews for a
provisional set of models. Picked sensors and operational state models.
Will be broadening from there. Looking at different ways to handle
units, etc. Going to work through these and find reasonable solutions.
Will get something out of the door soon but also will work on the harder
problems like breaking into modular features. Being able to describe
simple and complex sensors. Giving rise to discussions on classes,
instances, specialization, etc. Not working on fixed time goal but
planning to get provisional models out so that people can start using
them already.
For iotschema, built around same metamodel that everyone is using.
Schema.org doesn't want to go towards device specification but rather
more generic patterns. Will not be extending schema.org right away, but
what doing is re-aligning with OneDM and other ontologies so can align
how we talk about devices in physical world. Could be RDF front-end.
Also iotschema could be way to get RDF so that you can point to Thing
Descriptions. Have some proposals from Siemens on extensions to
metamodel so that we can connect to physical devices.
CB: very intersting since with SDF just had discussion on
relation(ship)s. Might have something we can point to instead of
re-inventing wheel. What is the best way for us to find out what is
going on there?
MJK: have cancelled the monthly meetings for a while but need to restart
that. No great answer right now but will try to start things going on
again. One observation: we see people knocking at door of WoT; have the
full set of problems of where the models go etc. We need to look at
better integration across all these. Already have W3C CG but didn't
really activate. WoT in middle of rechartering.
There is a gap to be addressed.
MMC: WoT would be open to add deliverables?
MJK: when people come to WoT they have questions beyond on what's the
format.
CB: seems like good subject for discussion soon. How to setup such
meeting to get progress on physical relation types and others we need
also in SDF long run
MJK: agree; good thing for WISHI too