WGs marked with an
Suit Status PagesSoftware Updates for Internet of Things (Active WG) |
Sec Area: Roman Danyliw, Benjamin Kaduk | 2017-Dec-15 —
Chairs:    |
IETF-109 suit minutes
Session 2020-11-20 1430-1530: Room 6 - suit chatroom
Minutes
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.