Minutes IETF102: t2trg
minutes-102-t2trg-00

# T2TRG IETF 102 Summary meeting
Thursday, July 19th, 2018, 15:50..17:50 EDT (UTC-04:00)

Note takers: Christer Holmberg, Eve Schooler, chairs

Github agenda: https://github.com/t2trg/2018-ietf102/

##  Intro, RG Status (Chairs)

Carsten presented the Next Steps in Security topics that will be presented
later (slide #5). Presenting the scope and goal of the T2TRG (slide #6).

Eve S: should be just focusing on constrained nodes? Edge computing, and other
cases with not only constrained nodes.

Carsten: Slide coming on the topic. Important one.

Presenting recent activities (slide #7).
WISHI (Work on IoT/Semantic Hypermedia Interoperability) - bi/tri weekly calls
and hackathons. Joint work with other SDOs: W3C, OCF (CoAP and CBOR related),
OMA SpecsWorks. Regular meetings with OCF on CoRE - partially research,
partially engineering.

Mohit: when security draft going forward?

Carsten: slight coordination still ongoing with IESG. Will be pressing publish
button very soon.

Identified research topics (slide #8)

1. We already have good ways to describe data models, now let's consider good
models that enable extracting info from byte strings and upgrading to data
model level of JSON/CBOR

2. Generate a working example of semantics in action (e.g., a light)

3. Protocol evolution

Robin Wilson: Correct; lights may seem simple, but aren't. Personally use as
example for privacy implications. Metamodel: on/off. Gap between UI exposed
data and data that is used. Privacy gap there. Could be security considerations
for research.

Peter vdS: How formal we want the models to be? UML, VDL?

Carsten: no idea at this moment. want to learn. If formal model helps, we
should. Let's see. Peter vdS: what is the added value needs to be considered

Next meetings (slide #9).
WISHI calls will continue.
Meetings with OCF (virtual and/or F2F).
Virtual meetings with OMA SpecWorks planned.
Bangkok#103: IoT Edge Computing session and in-network computing? WISHI
hackathon? Co-locating with academic conferences 2019? Community is asked to
suggested suitable events.

Edge and In-Network Computing (slide #10):
Harkens back to Active networks (wasn't particular successful - should try to
avoid those pitfalls this time around). Multiple RGs working with associated
activities: T2TRG, ICNRG, DINRG, PEARG. Joint meeting at IETF#103? Other
activities: e.g., presentation at IETF 100 on edge computing, recent
submission: draft-hong-iot-edge-computing.

RG doc status (slide #11):
State of the art and challenges for the IoT security: READY.
RESTful Design for IoT:
Hypermedia guidance included in -01.
More IoT specifics througout the draft: REST constrainst in IoT, IoT related
system characteristics. Since often cannot update all devices simultaneously,
need to accommodate protocol evolution. Next step: author review, then submit
new version for broader review.

Not a RG document (slide #14):
Survey: draft-sarikaya-t2trg-sbootstrapping.

Carsten: Do we have the energy/interest to work on this? Interested parties are
requested to talk to the chairs.

Kerry: commonality between this and the secure updates work?

Carsten: secure updates already in the SUIT WG. If interest moving forward,
provide reviews and perhaps even more material.

## Report from WISHI and Hackathon (Michael Koster, chairs)

Bi-weekly tel-meetings between IETF meetings.
Participation in IETF hackathons.
E.g., Topics include W3C WoT Thing Descriptions, processing models, terminology
for layers, integration of IoT with Energy, impact of JSON LD 1.1 work on Thing
descriptions, W3C plugfest and WISHI, iot.schema.org, etc. Work with other
SDOs, including automotive group GENIVI VSS. Good Thing description (slide 22).
Information and Data Models. Enables describing both "What I want to do" and
"How I want to do it".

WISHI hachathon objectives:
Test applications from different vendors/contributors.
Work focusing on mapping.
Example results: demo'd interop between generic clients and diverse devices, RD
implementation up to speed and ready to integrate with TD.

Peter vdS: discovery use cases and scenarios with security aspects?

Koster: lot of security aspects, including semantics. Who is allowed to
discover what, etc. Part of the workspace here.

Realized that we have a good and complete tool set - focus on using it.
Setup is still a big issue: took most of the 1st day of the hackathon

## iot.schema.org update (Michael Koster)

Used in WoT plugfests and WISHI hackathons. Validated basic schema.

## W3C update (Matthias Kovatsch)

What? Counter fragmentation in the IoT.

Building block: TD (Thing Description): data, events, and actions. JSON based
representation format.

Building block: WoT Binding Templates: mapping of interaction model to concerte
protocol operations (e.g., COAP).

Building block: WoT Scripting API: standardized JavaScript object API.

Mature work: started in 2014. Now almost in the end of original charter. Added
few months to the end of charter to acommodate for JSON-LD 1.1.

Simplified TD

- JSON-LD 1.1 processing
- Semantic annotations optional
- JSON schema compatiblity
- New terms

A few things still to do before the release.
IANA impacts: application/td+json and CoAP Content-Format number.
Align links field with draft-ietf-core-links-json.
Security and Privacy: Is needed, but much work will be outside the scope of the
upcoming relase. Work will continue.

Ari: if interested in semantics / hypermedia interop work, please join the
WISHI calls and hackathons. More information in the wiki and in announcements
sent to the mailing list.

## Next steps in security

### Automated IoT Security (Oscar Garcia-Morchon)

Draft: draft-garciamorchon-t2trg-automated-iot-security

Goal: solve mismatch between security capabilities and settings with which IoT
devices are designed/manufactured/deployed. Goal: Security reqs of IoT devices.

Problems: different environments, evolving threats, wrong pre-configuration.

PASC: Protocol for Automatic Security Configuration: provide security that fits
the specific deployment environment.

PAVA: Protocol for Automatic Vulnerability Assessment: automatic configuration
(PASC) based on continous vulnerability assessment. Benefits for manufactures,
sys ops and end users ("don't need to do anything").

Carsten: Looks interesting. Fits very well with the currently ongoing work.

Hannes T: How does the sec conf look like?
Oscar: Could be based on different methods (e.g., access control rules). If
have ideas or comments, send e-mail.

### Enabling Network Access for IoT devices (Mohit Sethi)

Why do IoT devs need access? Services in the cloud, software updates.

Problems: discovery and configuration (which network, which cloud server,...),
security bootstrapping.

Problem solved for laptops. How to do the same for IoT devices?

Challenges: limited UI, scalability, mere mortals setting up the network (vs
admins), range of wireless technologies.

Current methods for network access auth: manual, managed.

Interest in the RG to document these?

Hannes: Makes sense. Commit to review. Has own ideas.

Carsten: eduroam does this; we know the basic system works. In eduroam have all
the contracts for building federation. What is the legal framework that would
make something like this work? Bad actor could have EAP server that accepts
connections from who pays me.

Hannes: universal problems.

Mohit: how to redirect authentication queries from one service to another. Fine
if diverting to competing service.

Carsten: can be surprising threat models.

Börje: small manufacturer goes out of business; what happens with the device?

Mohit: this method actually helps in that case. Can direct your queries to
other place than just vendor. Open source community could take this. OpenWRT
devices can be flashed with own firwmare for example. Can peer with other
services too.

###  Next Seps in Security? (Rene Struik)

Focusing on crypto aspects.

Secure key material and storage - minimizing overall implementation cost.
Can we use only single public key pair for key agreement and signing? Saves
cost that could be used in other parts to improve security. Can use single
symmetric key? Do we need high-quality random seeds?

Hannes: did seminar on RNG topic. Went to see how common RNGs are in
microcontroller. Turned out that ST micro alone have +400 low-end
microcontrollers with RNG there. But you can also pick option that doesn't
have. Haven't checked other vendors yet. Good to remember that not all
microcontrollers are Internet-connected.

Well recognized that we need randomness in keys - could be that the
implementation of AES needs randomness as well. Not all things have home in
IETF. But good to point out.

In post-quantum world may need to send much longer packets due to longer key
and tag needs. Can be problem for constrained devices/networks.

Kristy Paine: AES256 pretty standard. With pub key crypto, discussion ongoing
to design new versions to be post-quantum resistent. Don't need to use large
parameters. Crypto agility is important; if something learned to be weak, needs
to be able to update.

Robin Wilson: how PKI ought to work (?). Spoke with PKI vendor; he said this is
going to be year of PKI. Said same two years ealier. 2009 shipped billion
PK-pairs. Not worth extra 15 cents to embed keys in certificates. Learning:
should always re-visit assumptions. Mass-deployment of PKI was in fairly dumb
devices, cable modems, set-top-boxes, smart meters. Don't bother having
management interface to change keys, would change device. Good to validate
assumptions. For these device cost-to-difficulty ratio? If solution to problem
is to replace a device, you may not care of all these problems.

How does one limit the impact of key compromise? Short-lived certificates at
reduced cost? could "ledger" as key repository help?

Other questions:
What about key provisioning, device config and commissioning?
What about privacy and control?
Bluetooth toothbrush that requires Internet connection to work is an existing
horror scenario.

### Decentralized Trust for IoT and In-network-computing (Dirk Kutscher)

"There is no JSON code in this presentation" :-)
Context: Industrial IoT, Multiple realms (a hierarchical depiction of the
network/devices and their control). Factory/Enterprise network as a
multi-tenant environment. China Mobile example: Beyond Edge computing. Data
Logistics - IoT data flows upstream and fusioning, which presents latency,
trust and scale issues. Therefore cloud-based model not always optimal.

Consider In-network computing with client-server protocols.
Implications of technologies such as Named-data networking (aka
Information-centric networking).

Vision: Compute-first networking, i.e., leverage increasing availability of
computation at different scales. Move away from the overlay approach and
integrating functionality instead into the network data plane.

Named Function as a Service (NFaas).
Treat unikernels as Named Data objects.
Trust management quite important in this environment, particularly since they
are compositional systems. Need to automate verification and enforcement. DINRG
to discuss what are the requirements for Decentralized Trust Management.

Carsten: Rene's work in LWIG and Dirk's work in ICNRG and DINRG tomorrow.
Interesting set. In the WISHI phone calls we will discuss semantics for
security (Which we didn't have time for today).