Reusability Considerations for Web Applications using HPKE

[dajiaji]

In addition to KeyConfig, the current OHTTP spec includes some OHTTP-independent components that can be reused by all applications using HPKE. For example, the following information in the Request Format (Section 4.1) must be defined by all of the applications acting as HPKE senders.

  Key Identifier (8),
  KEM Identifier (16),
  KDF Identifier (16),
  AEAD Identifier (16),
  Encapsulated KEM Shared Secret (8 * Nenc),

I'm thinking that the above information is very versatile and it would not be efficient to reinvent this kind of definition for every application that will do the HPKE transaction over HTTP in the future.

The same is true for the Nonce in Response Format (Section 4.2).

Isn't there any option to use an HTTP header (e.g., the new HPKE-Sender-Info header) to send the above information?

This idea introducing new HTTP headers for generic HPKE purpose would allow message/ohttp-req and message/ohttp-res to be merged into message/ohttp representing BHTTP encrypted data with HPKE, and would also have the side benefit of allowing the gateway to reject invalid HPKE sender information (invalid key identifier, etc.) without reading the request body.

I think it's not a bad idea to separate the application(OHTTP)-specific stuff in the payload and the generic HPKE parameters in the header. I would appreciate your comments on this opinion.

[martinthomson]

In defense of the current design:

• Efficiency is better this way. A header takes a lot more space when you consider the overhead of the field name and encoding.

• Reuse takes many forms. Repurposing the design is already possible. Your proposed field might seem to be reusable without additional work, but any application that reuses this design needs to define new constant strings for its interactions with HPKE. That means that you can't just plug the value in without also changing the content of those strings. If you failed to do so, then it is possible that you created a cross-protocol confusion attack. Keeping the configuration parts in the media type-specific part means that there is a better chance of avoiding copy-paste style errors like that.

[dajiaji]

• Efficiency is better this way. A header takes a lot more space when you consider the overhead of the field name and encoding.

Certainly, it is true that using the HTTP headers is less efficient, but like not optimizing Cookie or Authorization header value by putting it into the payload, I think the overhead is acceptable.

• Reuse takes many forms. Repurposing the design is already possible. Your proposed field might seem to be reusable without additional work, but any application that reuses this design needs to define new constant strings for its interactions with HPKE. That means that you can't just plug the value in without also changing the content of those strings. If you failed to do so, then it is possible that you created a cross-protocol confusion attack. Keeping the configuration parts in the media type-specific part means that there is a better chance of avoiding copy-paste style errors like that.

Each application using HPKE is responsible for defining the constant strings to be set in "info" and "aad", and the agreement on "info" and "aad" between the sender and the recipient of the application does not need to be implied in the communication protocol. Specifically, I think that the constant strings decided at the application layer does not need to be implied by the Content-Type header value (media type) because it has already been determined by the application (URL). For instance, I believe that when accessing the URL of OGR, it is already determined to be "message/bhttp request." (...why not "ohttp request"? If there were an application other than OHTTP that encrypts message/bhttp data, would there be any problems?)

I think the constant string discussion is not related to the discussion of using HTTP headers for the common parts of HPKE transactions. Did I misunderstand something?

[martinthomson]

My point was that - while the encoding and name of your proposed header field might be the same across different usages - the semantics and use of the information is not. That is, for OHTTP you would provide some information and for another payload type you would provide different information. That makes it less safe to use than would be ideal. A mistake in application would allow for confusion attacks.

Also, I don't believe that it is safe to condition behaviour on the URL. Though a resource might expect a certain type of content and be configured to accept only that content, that URL could be provided by the attacker in another context. If a client believes the URL accepts X, but it expects Y, the two will disagree and that tends to lead to confusion attacks.

"message/bhttp request." (...why not "ohttp request"? [...])

The idea is that OHTTP is generic. The formats could be replaced over time by different or better encodings. For instance, the HTTP working group is discussing options for header encoding that might not be simple text (note: HTTP fields are not simple text anyway, if you want to get really pedantic). OHTTP continues to work if you define a new message type, but it is important to tightly bind the message type into the encryption or we are back at the confusion attack thing.

[dajiaji]

(I couldn't have time to reply this workdays.)

That makes it less safe to use than would be ideal. A mistake in application would allow for confusion attacks.

Hmm, I don't think that defining a dedicated media type for an HPKE application is helpful to make the application use an unique info parameter value. They are different. In fact, in the current OHTTP spec, the info value and the payload data of 'application/ohttp-{req,res}' media type are different.

Furthermore, It does not seem practical that a web application that wants to use HPKE must define its own media type for every single one.

Repeatedly, each application is responsible for populating an application-specific info to the HPKE context and I believe it has nothing to do with the data container format used by the app. It means that defining a dedicated media type for an HPKE app is not helpful to mitigate the cross-protocol confusion attacks. At least, the measures introducing a dedicated media type for each HPKE app appears to be less effective than the complexity introduced. Am I wrong?

Also, I don't believe that it is safe to condition behaviour on the URL. Though a resource might expect a certain type of content and be configured to accept only that content, that URL could be provided by the attacker in another context. If a client believes the URL accepts X, but it expects Y, the two will disagree and that tends to lead to confusion attacks.

Forget about the URL stuff. What I wanted to say is that a typical way to protect against the cross-protocol confusion attack is for each app to take care of populating an app-specific info value to the HPKE context (or an app-specific aad value to each HPKE AEAD process), and this protection method is not related to the communication protocol or data format used at the application-layer.

My proposal (introducing the HPKE-Sender-Info header) is based on the idea that info/aad-related information (media type?) does not need to be exchanged between the sender and recipient of the HPKE application, but encapsulated_key, key ID for KEM and selected HPKE cipher suite information (KEM, KDF and AEAD) need to be exchanged on all HPKE applications, and it is reasonable to transmit this mandatory information in a common HTTP header.

In addition, I believe that the introduction of the HPKE-Sender-Info header would be helpful not only for other HPKE applications using HTTP, but also for ORRs to guarantee the key consistency of OGRs to their clients. By observing this header, the ORRs would be able to easily detect the key consistency violations of the OGRs.

[dajiaji]

In addition, I believe that the introduction of the HPKE-Sender-Info header would be helpful not only for other HPKE applications using HTTP, but also for ORRs to guarantee the key consistency of OGRs to their clients. By observing this header, the ORRs would be able to easily detect the key consistency violations of the OGRs.

Sorry, this is not true. I retract it.

If the key identifier could be a hash value of the public key like the typical kid of JWK, the HPKE-Sender-Info header would be useful for ORRs to detect the key consistency violation at OGRs though.

[martinthomson]

It does not seem practical that a web application that wants to use HPKE must define its own media type for every single one.

This is really what HTTP expects to have happen. Distinct media types for distinct formats. We can define a parameterized media type to ease the passage somewhat, but the vnd+ prefix should make it easy to define a proprietary media type.

[dajiaji]

Hmm, my point is that whether or not to use HPKE and whether or not to define an application-specific media type are essentially orthogonal and the HPKE stuff can be separated from the media-type by the HTTP header for HPKE.

In any case, your explanation helped me understand the current OHTTP design philosophy. Thank you very much.

[martinthomson]

Marking as resolved.