-
Notifications
You must be signed in to change notification settings - Fork 19
Description
The first draft of the security audit highlighted several small items that ought to be fixed before we move to a release version.
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.