You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Based on our work with the SSF specification, we suggest the working group consider the following
changes. Most of these are based on (necessary) assumptions explained in Section 2 and we note
that our model reflects the specification with these changes.
Issuer Identifier Validation.
While the configuration discovery specification mandates Transmitters to only use issuer identifiers with the https scheme [10, Section 6.1], there is no requirement
for Receivers to only request configuration documents from https URLs. If a Receiver requests a
Transmitter’s configuration document from an http URL, a network attacker may launch an MitM
attack, resulting in the Receiver accepting arbitrary, attacker-chosen configuration data (including
JWKs) and arbitrary, attacker-chosen SETs. We, therefore, recommend explicitly mandating Receivers to (1) obtain Transmitters’ issuer identifiers from trusted sources, and (2) verify that these
issuer identifiers use the https scheme.
In our model, we assume that these recommendations are implemented (see Section 2.5).
Stream Configuration Management API Endpoints.
The current SSF specification does not
mandate the use of https for any of the stream configuration management API endpoints. We
note that for SET delivery, [RFC8935, RFC8936] mandate the use of https URLs, and of course
recommend mandating Transmitters to use https URLs for all stream management API endpoints
and the JWKs endpoint.
In our model, we assume that this recommendation is implemented (see Section 2.5).
Requirements on Additional SET Delivery Methods.
In our model, we only consider the push
and poll delivery methods as defined in [RFC8935, RFC8936] (see Section 2.2). This implies that
in our model, SET delivery always takes place via TLS-protected connections. However, the SSF
5
specification does not limit allowed delivery methods to these two. Hence, we recommend requiring
the use of SET delivery methods that ensure SET confidentiality and integrity.
The text was updated successfully, but these errors were encountered:
PR #173 requires TLS for all stream management endpoints
Requirements on Additional SET Delivery Methods
I think this issue might already be addressed. In section 7.1.1, the method field of the delivery object in the Stream Configuration data restricts the delivery options to either push or poll.
The first draft of the security audit highlighted several small items that ought to be fixed before we move to a release version.
2024-04-09_WP4.1a-Report.pdf
The relevant sections have been copied below.
3. Notes on the SSF Specification
Based on our work with the SSF specification, we suggest the working group consider the following
changes. Most of these are based on (necessary) assumptions explained in Section 2 and we note
that our model reflects the specification with these changes.
Issuer Identifier Validation.
While the configuration discovery specification mandates Transmitters to only use issuer identifiers with the https scheme [10, Section 6.1], there is no requirement
for Receivers to only request configuration documents from https URLs. If a Receiver requests a
Transmitter’s configuration document from an http URL, a network attacker may launch an MitM
attack, resulting in the Receiver accepting arbitrary, attacker-chosen configuration data (including
JWKs) and arbitrary, attacker-chosen SETs. We, therefore, recommend explicitly mandating Receivers to (1) obtain Transmitters’ issuer identifiers from trusted sources, and (2) verify that these
issuer identifiers use the https scheme.
In our model, we assume that these recommendations are implemented (see Section 2.5).
Stream Configuration Management API Endpoints.
The current SSF specification does not
mandate the use of https for any of the stream configuration management API endpoints. We
note that for SET delivery, [RFC8935, RFC8936] mandate the use of https URLs, and of course
recommend mandating Transmitters to use https URLs for all stream management API endpoints
and the JWKs endpoint.
In our model, we assume that this recommendation is implemented (see Section 2.5).
Requirements on Additional SET Delivery Methods.
In our model, we only consider the push
and poll delivery methods as defined in [RFC8935, RFC8936] (see Section 2.2). This implies that
in our model, SET delivery always takes place via TLS-protected connections. However, the SSF
5
specification does not limit allowed delivery methods to these two. Hence, we recommend requiring
the use of SET delivery methods that ensure SET confidentiality and integrity.
The text was updated successfully, but these errors were encountered: