# IOTOPS @ IETF 116   {#iotops--ietf-116}

Friday, March 31st, 2023  
12:00 (Japan)/03:00 (UTC)  
1.5 hours

Meetecho:  
https://meetings.conf.meetecho.com/ietf116/?group=iotops&short=&item=1  
Notes: https://notes.ietf.org/notes-ietf-116-iotops

Chairs: Alexey Melnikov and Henk Birkholz

Note takers: John Preuß Mattsson (and Henk when John cannot do it)

# A summary of security-enabling technologies for IoT devices.   {#a-summary-of-security-enabling-technologies-for-iot-devices}

Brendan: Integrated NIST IoT cybersecurity core baseline. Should rename
draft.

Brendan: The draft is likely to keep expanding. Need more authors to
handle the mappings to ETSI, IoTSF, GSMA, etc. Should we have 1 draft
per source?

Michael Richardsson: Agree that ETSI should be next but not so much
original content in the ETSI doc. I am willing to be author but I don't
think this needs to be long

Carsten from the chat: +1 MCR don't break it up

Alexey: I second what you said. A lot of overlap. Think it should be one
document. The document will be a snapshot. At some point we should say
this is good enough.

Erik Nordmark: +1 don't break it up. It is fine to freeze it.

Brendan: Seems like consensus.

# Comparison of CoAP Security Protocols   {#comparison-of-coap-security-protocols}

John(pres): Document history - discussed in CORE, discussed in LWIG,
adopted in LWIG, now adopted in IOTOPS.

Carsten: clearly differentiate unstable protocols (e.g., "ctls-07", not
ctls); maybe mention SCHC (alongside GHC) but there aren't that many
established practices here, so the impact of SCHC on various protcols
maybe should be a separate document.

Christian (from chat): CoAP-over-TCP is basically the baseline for
CoAP-over-TLS (which John agrees with)

Bill: *\_\_*

Marco: The way the sizes were derived should be documented. The message
size for Group OSCORE pairwise responses as a funtion of the OSCORE
Sender ID should be lower than that. See also:
https://mailarchive.ietf.org/arch/msg/iotops/fxwOWBGTFb6pDzttkyYgGuLhdn8/

# ACME-Based Provisioning of IoT Devices   {#acme-based-provisioning-of-iot-devices}

Michael: Extend ACME so you can do it locally. Covers both home and
enterprise networks. Let's encrypt does not work for .local. Document
describes practices and considerations for how to use ACME on local
network.

Brendan: I think the identity of the ACME server is the network
identity.

Christian: Plan for how this could end up in actual browserd? Do we
really need to know that a printer belongs to my network?

Michael(from chat): Don't try to solve the enterprise case. MAybe have a
desgin team.

Wes: What prevents one node to steal another node's name or prevents
someone to set up a ACME server.

John: Should be solved, but is hard. Thousands of CA and self-signed is
not really the pinnacle of trust. Level of Trust seems to be unrelated.

Alexey: Did you bring this to ACME working group. Would be good to
present this in the ACME WG next IETF.

Warren: Have you been talking to the browser folks.

Brendan: Grandma tries to reach the printer but get's something that
looks like a bank login page. We need a solution to that attack. A
compromised printer.

Alexey: We will come back to you with design team discussion.

# "Power of Attorney"-based onboarding   {#power-of-attorney-based-onboarding}

Sreelakshmi: How can we reuse this technique to onboard IoT devices.
Updates in latest draft are clarification, more related drafts, and more
discussion on FIDO and CBOR. PoA library available. Another draft
explain PoA in OAuth. Reviews and comments welcome.

Olov: Also a draft comparing PoA with other proposals.