2025-04-security

T2TRG interim meeting on security topics.

Time: Thursday, April 3rd, 15:00 UTC

Intro

Ari Keränen (AK) doing introduction.

AK: We're thinking of one more interim meeting before the summer on data
modeling. Then a summary meeting face-to-face at IETF 123 in July.

Karolína Skřivánková: Why is my smart home still dumb? (Teaser)

Slides

Karolína Skřivánková (KS) presenting.

KS: Tension between scalability and dependability in building
management/control. Policies should ideally be valid for decades, but
things can radically change in the meanwhile. To complicate: devices are
flaky, as are wireless links. So also tension between simplicity and
other (non-)functional properties.
KS: Expectation that all parts will be changed over time (ship of
Theseus style).

KS: Going via server requires going though flaky link twice.
KS(p16): Removing server from critical control path (not completely
gone).

KS: Hard reality constraints: SW very much tight to HW and leaving
little freedom. Often SW quality is a concern. (Good) updates are not to
be taken for granted. Different parts of the SW should evolve
independent from one another and from the HW development. That enables
decisions on what SW to run and when.
KS (p30): Split up control policy into software chunks.

KS (p40): Restartable calculations can lead to better resilience.
KS (p44): No system call interface in WASM. Interface via message
channels.

KS: Lifecycle of previous application. SW chunks from a server and
loaded on the devices. Later on, we might want to include better
devices, which introduces a new data flow. More processing can actually
be put on / offloaded to better capable devices. This has the risk to
have a desired functionality not taken care of anymore, with consequent
restart to restore the full set of desired functionalities.

KS (p55): Device was less reliable than expected, orchestrator can
upload task somewhere else.

KS (p60): Results from evaluations on ESP32. Switching from a native to
a containerized implementation about doubles the latency for command
propagation, but still negligible for many applications.

KS: Summary of practical needs: componentization, portability, dynamic
component placement.

Carsten Bormann (CB): On scope with the intended direction of the RG for
the next 5 years. Work started for mobile code (e.g., Klaus Hartke's
Mango around 2018), but we didn't have containerization solutions. This
looks like a bright future.
KS: We see it possible to build the required abstractions and be
flexible.
CB: We need to get beyond the stereotypical IoT concept and really into
what we mean more broadly with Thing-to-thing.

Christian Amsüss (CA): When viewing messages from REST PoV, could match
well with dynlink work in CoRE WG; this could be valuable input for
driving that standardization effort. Have looked how to transfer
messages, e.g., CoAP?

KS: now more theoretical. Like unreliable (measurements) and reliable
delivery (events, commands). Haven't looked at CoAP and state transfer
much but will look into that.
CA: happy to play around with this

CA: 64k page size limitation?
KS: ESP is really on the edge, "constrained device" typically suggests
still more capable ARM devices or so.
CA: can put in contact with people working on these topics.
(https://dl.acm.org/doi/pdf/10.1145/3528535.3565242)

CB: One technology to mention here is Rust as a language.

Carsten Bormann: Report from IETF 122 meeting security discussions

Slides

CB presenting summary from 4 IETF groups/BoFs from IETF 122 (there are
many more with relevant work), from players/objectives/beliefs PoV.

CB: SCONE WG, working on ways for endpoints to obtain information to use
for well using the network and its resources. Focus on the QUIC protocol
and its endpoints asking the network on properties about rate limits. A
TRONE protocol packet is coalesced into a single UDP packet together
with a QUIC packet.
CB: Those who can modify TRONE information can already influence data on
the path (e.g., rate limit). This might happen in the constrained space,
e.g., thinking of OSCORE that has some flexibility about what can be
protected to what extent.

CB: On the NASR BOF, working on ensuring that network packets take a
"secure" path, while attesting the status of traversed routers.

CB: Work on the selective disclosure protocol in SPICE for SD-CWT and in
OAuth for SD-JWT. The token holder can be selective on the disclosed
claims from the token. The key is the ability for the holder to redact
the claims in the token, while keeping the verifier able to verify the
original signature of the issuer that produced the token with all the
claims in (leveraging some cryptographic tricks).

CB: Then the SCITT WG on ensuring transparency and attribution of signed
statements made by suppliers.
Interesting to look how the roles (slide 11) would look like in IoT
setting.

Mohit Sethi: "Terminology and processes for initial security setup of IoT devices" update

Slides

Mohit Sethi (MS) presenting

MS: Overview of common terms used for IoT device setup, trying to
understand how they are used and their commonalities.

MS: Another goal is also a comparison of assumptions made in the context
of device setup.

MS: Another thing to cover is a list of protocols that are typically
used for device setup.

MS: Recent updates to the draft are about more extensive definitions of
common terms.

MS: We need reviews.

Michael Richardson (MCR, on chat): Mohit, please schedule some design
team meetings to help progress more text.
AK: That makes sense. Also, please review.

MS: So far we have mostly covered IETF protocols. We can find some
colleagues to confirm we're on the right path and cover also other
protocols.

Michael Richardson: "A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors" update

Slides

MCR presenting

MCR: This has been sitting around for a while. Recapping why it's
important: there's a belief that manufacturers are not so good in
managing keying material, and about other security-related tasks. It's
hard to know which manufacturers in the supply chain are actually good
or bad.

MCR: The solution is about involving an auditor, but we can we define a
clear list for auditors to consider for their process?

MCR: Proposed terminology and taxonomy, e.g., about different methods
and points in time for key generation.

MCR: I would like more feedback/discussion on the names. They can be
trimmed down to single letters. Is it ready to be published?

AK: Don't have good proposals for names, but I'd like to hear any
proposed names from the NIST discussion.
MCR: unfortunately there were none.

MS: Goal is to help auditors who visit factories to ensure they discuss
the same things.
MCR: Auditors do this today; manufacturers will have their process
audited. Reports remain confidential. Goal is to describe terms they are
willing to publish. For example, I removed term "Bus count of a
project". Turns out, with secret sharing of PKI root, "how many shares
can you lose before you have a problem?". Count can be public, whether
it's 5/7 or 9/11 is not needed to know outside of organization. (cf. DNS
root trouble with key signing ceremony; was audited).
MCR: sorry. I mispoke. The delta (9-7=2) could be public, but the 9 and
the 7 probably don't need to be.

AK: Discuss face-to-face?
MCR: Let's do that earlier!
AK: So please all post your name suggestions and discussion on the
mailing list.

Christian Amsüss: "Raytime: Validating token expiry on an unbounded local time interval"

Slides

CA (prep): slide 6: s/WG/RG/

CA: Often an IoT device is intermittently on/off, typically sleeping and
barely able to take a round-trip. At first, it seems like it's either
failing or tolerate expired tokens.

CA: This document explores alternatives (but it seems there's none),
gives a model for expressing time, and provides considerations on the
consequences.

CA: Is this RG a good venue? How can it progress? Any more items that I
can consider as background reference? I am working on an implementation.

CB: Nice example of "if you don't like the solution, change the
problem". The classic problem in this area is unsolvable, so we can
relax the objectives to make a new simpler problem solvable. It reminds
of the ESNI work in TLS, something that cannot be entirely solved in its
full flavor, but practically so under the right assumptions and still
with acceptable benefits. I would like to see progress on this.

CB: Discuss with a strong view towards the deployment economy, i.e.,
what is the benefit that deployers will get from it.
MS (chat): yes. interesting problem to work on in general.

AK: Have you looked at 3GPP networks as source of timing data?
CA: They are a source of data, but if you can access those, you're
basically online. I am considering a case without connectivity and
service. Maybe this won't be needed when we have a fully electrified
atmosphere. If you can access a 3GPP network, use it. (Whether or not
it's trustworthy is a different issue, but I wouldn't consider that an
unconnected case).

AOB

CB: comparing to the ICANN safe-drill in the chat discussion: What's the
backup strategy? (We tend to design systems for the cases where they
work; what when not?)

MS: Cloud secret sharing now used more widely?
MCR: As far as I know, these solutions are expensive (e.g., 400 USD per
certificate). There's a market mismatch between what peopla are willing
to pay and the costs of these things.
CB: It used to be 100 USD per certificate per year some time ago. In the
long run, that changed. It's interesting to look from the players'
objectives. Sometimes you have to invent the right players.
CB: For SCITT, the innovation was identifying the "transparency service"
as a commercially viable player that can provide essential service in a
way that fosters competition.

Wrapup

AK: Let's continue on the mailing list. Again, planning one more interim
soon, then the face-to-face meeting at IETF 123.