Add zero-trust-preproposal #1301
Conversation
This commit adds the zero-trust-preproposal.md file which explores the various protocols to find their limitations around metadata which is a great place for signatures or any other security related information to live. Signed-off-by: benjamin-j-powell <[email protected]>
Signed-off-by: benjamin-j-powell <[email protected]>
| ### AMQP | ||
|
|
||
| AMQP supports metadata similar to how HTTP handles this. For AMQP, headers live within the message itself. These headers live within the AMQP message meaning that the headers are sent along with the payload, while HTTP sends headers prior to the payload being sent. | ||
|
|
There was a problem hiding this comment.
That is not how AMQP does headers. AMQP (we only support the actual standard here: AMQP 1.0) has an "application-properties" section into which the CloudEvents headers are mapped in the "binary" mode. AMQP has three other sections that can contain user-defined metadata: footer, delivery-annotations, and message-annotations. Nearly all fields in the pre-defined "properties" section are also application controlled.
|
|
||
| ## Abstract | ||
|
|
||
| The ultimate aim is to add zero trust capabilities to cloudevents. To achieve this, we will create two proposals. The first proposal, which we will call the pre-proposal, will explore the different protocols to understand their limitations and how we can implement zero trust. The second proposal will design the implementation of how we can achieve zero trust in cloudevents.. |
There was a problem hiding this comment.
You'll have to define what "zero trust" means in this context and what feature you are looking to add specifically to CloudEvents and not to the individual protocols. If you want to create some end-to-end security assurances for AMQP, you're invited to bring those forward to the OASIS AMQP TC (which I'm the chair of) and if you want to do the same for MQTT, the OASIS MQTT TC will surely also consider it, but it's not within the scope of the CloudEvents WG to create companion specs for protocols. We map CloudEvents onto the existing facilities of protocols.
|
|
||
| It is important to note that cloudevents’ protocols operate at the application level, encompassing both encodings and wire protocols. This analysis will separate encodings from wire protocols, as encoding refers to the format in which data is sent and does not restrict the security libraries or tools we can use, unlike wire protocols. | ||
|
|
||
| The primary focus will be on where metadata can be stored, such as headers in the HTTP protocol, in each protocol, rather than an in-depth examination of each protocol. Having a place to store metadata per request will allow us to configure and send any necessary security-related information, facilitating the implementation of zero trust. This proposal will not delve into various security algorithms or tools to be described in the metadata. |
There was a problem hiding this comment.
Each CloudEvents transport binding (really: application protocol binding) has a well-defined way of how CloudEvents attributes map to the respective application protocol message. That analysis has been done and we have SDKs that implement these mappings in tghe CloudEvents project and there are other implementations that also use these mappings. An extension to CloudEvents cannot step outside these boundaries and a CloudEvents extension MUST be expressed solely in terms of the abstract Cloudevents metadata model. You can add extra attributes, but an extension cannot modify the interaction with the application protocol messages.
|
|
||
| ### HTTP | ||
|
|
||
| HTTP supports a metadata format known as [headers](https://datatracker.ietf.org/doc/html/rfc2616#section-4.2). The HTTP RFC does not specify a limit for header sizes, but it is important to call out that implementing web servers MAY have some limits set, at least as some default. For example, Apache HTTP server defaults to a max header size of 8KB. |
There was a problem hiding this comment.
The latest RFCs for HTTP are RFC9110-9114. You are referring to section 6.3 of RFC9110 https://www.rfc-editor.org/rfc/rfc9110#name-header-fields
|
|
||
| However, because of the need to encode these headers a certain way, the producer and consumer MUST agree on some encoding for them to understand the contents of the headers. | ||
|
|
||
| It is important to note that since Kafka is architected as a producer and consumer messaging service, any consumer ingesting message will see the contents of the headers. I do not think this affects zero trust, but it is something to think about when we write the technical specification for zero trust. |
There was a problem hiding this comment.
This is generally true for all messaging scenarios. The receiver of an HTTP POST can see all the headers in a webhook delivery scenario.
|
|
||
| ### Kafka | ||
|
|
||
| Headers are a concept within Kafka since v0.11.0, and I’d argue a little more powerful than HTTP headers. The biggest benefit is that headers in Kafka are actually byte arrays. Meaning header values allow for more complex encodings, unlike HTTP where header values are generally textual. |
There was a problem hiding this comment.
CloudEvents mandates that both header values and keys MUST be UTF-8 strings: https://github.com/cloudevents/spec/blob/main/cloudevents/bindings/kafka-protocol-binding.md#323-metadata-headers
|
|
||
| It is important to note that the format of variable headers is dependent on the MQTT packet type, and that variable headers are only available in a subset of the MQTT control packets. | ||
|
|
||
| * PUBLISH (only when [QoS](https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/) > 0) |
There was a problem hiding this comment.
The CloudEvents MQTT binding only binds to the PUBLISH message: https://github.com/cloudevents/spec/blob/main/cloudevents/bindings/mqtt-protocol-binding.md#3-mqtt-publish-message-mapping
|
|
||
| ### WebSockets | ||
|
|
||
| WebSockets are a high-level abstraction of the TCP protocol. They utilize HTTP to first provide the handshake and then upgrade to a full-duplex TCP connection. This means that metadata is primarily restricted to what can be sent during the initial handshake. Consequently, WebSockets are more restrictive in terms of metadata transmission compared to other protocols. |
There was a problem hiding this comment.
WebSockets are a framing protocol enabled as a subprotocol of HTTP. It's NOT a raw TCP connection, because WebSockets overlays a framing layer that supports binary and text frames, see https://www.rfc-editor.org/rfc/rfc6455#section-5.2
The CloudEvent WebSockets binding only supports structured mode, which means that the metadata is embedded inside the WebSocket frame.
|
|
||
| ### AVRO | JSON | Protobuf | XML | ||
|
|
||
| These are the encodings that cloudevents supports: AVRO, JSON, protobuf, and XML. Encodings do not affect whether we can rely on metadata, and will have no hindrance on the implementation of zero trust. |
There was a problem hiding this comment.
Encodings apply when the encoding mode is "structured", which means that outside of the content-type indicator, the CloudEvent has no relationship with the transport that carries it. I can print a JSON CloudEvent on a sheet of paper and send that via the postal service and the receiver receives a perfectly valid and consistent CloudEvent.
|
|
||
| ## Summary | ||
|
|
||
| We have explored each wire protocol, and while some have more limitations than |
There was a problem hiding this comment.
Any extension must indeed ignore all of these details and stay within the framework set by CloudEvents. If you want to provide end-to-end security for CloudEvents, the focus must be on the CloudEvents attributes.
It appears feasible to apply S/MIME (https://datatracker.ietf.org/doc/html/rfc8551) to CloudEvents in the following (theoretical) model:
- Map the CloudEvent to the "Internet Message" using the CloudEvents HTTP binding. The HTTP 1.1 message is a superset of the "Internet Message" model that is also used for SMTP.
- Process the message using S/MIME for signature and/or encryption.
- The result is an Internet Message that has now the desired security attributes applied.
- You will then stash the entire resulting message into the "data" section of a wrapping CloudEvent, whose datacontenttype is "multipart/signed" or another applicable S/MIME format. The CloudEvents attributes that are okay to travel in the clear are copied onto this wrapper CloudEvent. You MUST copy all required CloudEvent attributes onto the wrapper: id, source, type, specversion. If that leaks too much data, you need to obscure the fact that you are sending CloudEvents at all.
Now you have a signed or encrypted CloudEvent.
Any receiver reverses the process, whereby it MUST check that the attributes that have been provided on the wrapper CloudEvent are exactly the same as in the contained, signed CloudEvent and that all the signatures are correct.
|
Discussed in SIG. Will move this to an issue where zero trust in general can be talked about |
This commit adds the zero-trust-preproposal.md file which explores the various protocols to find their limitations around metadata which is a great place for signatures or any other security related information to live.
This is 1 of 2 proposals for zero trust. This initial proposal is to investigate each protocol and look into their limitations around metadata support which we will use to pass any necessary information to help verify any incoming requests.
Proposed Changes