search

ietf-wg-scitt / draft-ietf-scitt-architecture

An Architecture for Trustworthy Digital Supply Chain Transparency Services
Other
11 stars 14 forks source link

TLS not mandated by the architecture #291

Closed hannestschofenig closed 3 weeks ago

hannestschofenig commented 3 months ago

All contents exchanged between actors is protected using secure authenticated channels (e.g., TLS) but may not exclude network traffic analysis.

This sentence in the security consideration section gives the reader the impression that communication security is assumed to be used. This is, however, not even discussed in the body of the document.

aj-stein-nist commented 2 months ago

Does the TLS requirement belong in the architecture or SCRAPI? I could see a case for either, but the architecture does not mandate only HTTP and or another application layer protocol that explicates TLS, but I know others have not presented an alternative application/transport layer that would prevent the TLS requirement, so I guess I get feedback with a PR.

JAG-UK commented 2 months ago

Does the TLS requirement belong in the architecture or SCRAPI?

The architecture document needs a Security Considerations section. What is in that section is of course up to the authors.

aj-stein-nist commented 2 months ago

Does the TLS requirement belong in the architecture or SCRAPI?

The architecture document needs a Security Considerations section. What is in that section is of course up to the authors.

OK, it is unclear if a potential change should explicate TLS or just clarify a "secure authenticated channel" is required and can be referenced in those security considerations.

I guess it is time for me to just PR a change and get supportive or constructive feedback than. 😅

JAG-UK commented 2 months ago

I think a deeper issue is that it's not clear that an authenticated channel is actually required in most cases. The Signed Statement is inherently integrity protected and carries strong Issuer identity so then we come down to questions that are definitely SCRAPI-specific (and SCRAPI has a Security Considerations already) and/or make recommendations focused more on confidentiality only

aj-stein-nist commented 2 months ago

I think a deeper issue is that it's not clear that an authenticated channel is actually required in most cases.

I was going to counter with some whataboutism and say "what about RFC9162!?" but it seems you are right. In the Security Considerations and elsewhere they never really explicate that, so your point stands.

I guess I would be interested in how this "frees up" TS instances conformant to the architecture that do not strictly use HTTPS and TLS a la SCRAPI, but that is outside the scope of this document and SCRAPI too, so I will leave my comment there for now. 😄

SteveLasker commented 1 month ago

Proposing we close, and leave TLS to be API specific (aka SCRAPI)

If no objections, or more specifically no PRs are submitted by Oct 8, 2024, I propose we close this issue.

aj-stein commented 1 month ago

Proposing we close, and leave TLS to be API specific (aka SCRAPI)

If no objections, or more specifically no PRs are submitted by Oct 8, 2024, I propose we close this issue.

I support closing it out, and I can support waiting until October 8th as well. :smile: