Skip to main content

Minutes IETF109: suit
minutes-109-suit-00

Meeting Minutes Software Updates for Internet of Things (suit) WG
Title Minutes IETF109: suit
State Active
Other versions plain text
Last updated 2020-11-24

minutes-109-suit-00
SUIT Working Group at Virtual IETF 109
===

Agenda
------
1) Logistics
   - Agenda Bashing
   - Minute Taker
   - Jabber Scribe
   - Bluesheets

2) SUIT Architecture
   - draft-ietf-suit-architecture
   - Discuss any issues raised by IESG evaluation

2) SUIT Information Model
   - draft-ietf-suit-information-model
   - Discuss any issues raise by IETF Last Call

4) SUIT Manifest Format
   - draft-ietf-suit-manifest
   - Discuss open issues; get ready for WG Last Call

5) Secure Reporting of Update Status
   - draft-moran-suit-report
   - Discuss open issues; get ready for WG call for adoption

6) Strong Assertions of IoT Network Access Requirements
   - draft-moran-suit-mud
   - Discuss open issues; get ready for WG call for adoption

7) Any Other Business (if time permits)

Jabber: xmpp:suit@jabber.ietf.org?join
MeetEcho: https://www.meetecho.com/ietf109/suit
Etherpad: https://codimd.ietf.org/notes-ietf-109-suit#

Notes:
---
1) Logistics
   - Agenda Bashing
   - Minute Taker
   - Jabber Scribe
   - Bluesheets

Note Taker: Hannes Tschofenig

Russ started with the introduction and gave a status update.

---
2) SUIT Architecture
   -
   [draft-ietf-suit-architecture](https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/)
   - Discuss any issues raised by IESG evaluation

Brendan spoke about the comments from the IESG. The feedback was positive.
Editorial changes and clarifications will, however, be needed.

Question about whether references should be normative or informative.
Brendan believes the references should be informative and forward references
are OK.
DaveT agrees. TEEP depends on SUIT and RATS. RATS does not depend on SUIT.
Russ agrees.

No disagrement to keep the references informative.
Hannes created PRs to address the editorial review comments.

---
2) SUIT Information Model
   -
   [draft-ietf-suit-information-model](https://datatracker.ietf.org/doc/draft-ietf-suit-information-model/)
   - Discuss any issues raise by IETF Last Call

Brendan mentioned that there were only two reviews.
GenART says the document is fine. SecDIR review says that it is not ready.
SecDIR review suggests to change the title of the document to "Information and
Threat Model". Russ and DaveT have no objections.

Suggestion to change the order. Currently it is Elements, Threats and
Requirements. Initially it was Threats, Requirements, and Elements. Proposal is
Elements, Requirements, and Threats.

Henk: Whatever order you select, it is the wrong one. Proposal: threats,
requirements, elements DaveT: I prefer order it is in right now.

Henk agree that the document should be labled "Threat Model and Information
Model" then the body of the document. This is also less work.

Agreement is to go for re-ordering to threats, requirements, and elements. Add
a note early in the document to allow the reader to jump to the elements.

Clarifications needed for OPTIONAL vs. REQUIRED with the text around
serialization. Need to split what is OPTIONAL and what is REQUIRED.

There was a question by the reviewer about appropriately referencing the
Microsoft STRIDE document. DaveT will find out whether there is a better link
to the STRIDE document. DaveW: STRIDE is discussed in Shostack (2014). *Threat
Modeling: Designing for Security*. Wiley. pp. 61–64. ISBN 978-1118809990. It
might be good to use this as the stable reference.

Russ: Having a stable reference would be useful for the community (beyond the
SUIT working group).

Matt: Clarification question about the SUIT specification.

---
4) SUIT Manifest Format
   -
   [draft-ietf-suit-manifest](https://datatracker.ietf.org/doc/draft-ietf-suit-manifest)
   - Discuss open issues; get ready for WG Last Call

Brendan goes through the changes in the SUIT manifest specification.

Topics:

- Private enterprise numbers

No concerns were raised about the approach as documented.

- remove SUIT_Digest from COSE payload

No concerns about the change. We are using the COSE mechanism in detached mode.

- Add CBOR tags

Asked if anyone has a preference for the 3-byte tag value.
DaveT suggested 107.

- Index lists

No comments about the change.

- SUIT_Report removed

No comments about the change.

- Editorial changes

Thanks to DaveT for his extensive review.

DaveT raises a question that surfaced in the TEEP group regarding component ids.
The current TEEP protocol draft suggests to use COSWID but the SUIT
specification uses UUID.

Brendan: The TEEP protocol draft should tell what content to put into the
component id. SUIT will always have a component id and may carry a COSWID but
it may be stripped someone along the path.

DaveT: In a small editors group we concluded that SUIT does not need changes.

Henk: There is a draft -- suit-claims-id. There is a system property claim that
is contains a component id. It may be included in the EAT draft.

Matt: Should a PEN OID entity be required to publicly present their information
in the same format?

Matthew Gimore (Matt, in chat): How would SenML fit with a SUIT manifest?
Brendan: I don't know SenML and cannot answer the question.

DaveT: I don't see the overlap with SUIT.

DaveT: Refers to an email he posted to the list (see
https://mailarchive.ietf.org/arch/msg/suit/dBSWDXWxK0kl21XTw_RpQNyMEf0/).
Asking whether SUIT should talk about installing/deleting/updating payloads.

Brendan: Sees challenges with introducing delete operations. He believe the
TEEP use case is orthogonal to the SUIT use case.

DaveT: The issue can come up when you install multiple independent components.

Brendan: I have to think about this aspect. We need to think about cases where
there are multiple copies of a component.

DaveT: TEEP has to express the components that are installed and there has to
be an identification that there is a need to identify it uniquely. We currently
do not have the answer but I believe the solution has to go into SUIT.

Brendan: Will post a mail to the list.

---
5) Secure Reporting of Update Status
   -
   [draft-moran-suit-report](https://datatracker.ietf.org/doc/draft-moran-suit-report/)
   - Discuss open issues; get ready for WG call for adoption

Reporting what the manifest processing did. If you have a copy of the manifest,
what do you need to do a backtrace.

DaveT: question to DaveW and Russ, should we ask for adoption at this time? The
TEEP protocol took a dependency on this document in the hope that the group
would adopt it.

Russ: I have no objection; does anyone object to start a call for adoption?

I see no objection - only support.

**ACTION: The chairs will discuss with the SecAD if a recharter is needed or if
it is ok to start a call for adoption.**

---
6) Strong Assertions of IoT Network Access Requirements
   -
   [draft-moran-suit-mud](https://datatracker.ietf.org/doc/draft-moran-suit-mud/)
   - Discuss open issues; get ready for WG call for adoption

Already discussed at
[IETF#108](https://datatracker.ietf.org/meeting/108/materials/minutes-108-suit-03.html).
The idea is to convey MUD info in SUIT.

Russ: Should we adopt this document?
DaveT: At the previous IETF we had talked about what the right WG is and the
conclusion was SUIT. DaveW: We do need to re-charter.

**ACTION: The chairs will initiate the re-chartering process**

---
7) Any Other Business (if time permits)

No time was available.