search

ietf-wg-privacypass / draft-ietf-privacypass-consistency-mirror

K-Check protocol specification
Other
0 stars 5 forks source link

Does this really need binary HTTP? #25

Open martinthomson opened 8 months ago

martinthomson commented 8 months ago

I like RFC 9292, but it seems like maybe it is unnecessary for this use case. The reason that RFC 9292 is used here appears to be that the header fields from the request that the mirror makes of the mirrored resource need to make it to the client. However, there is no end-to-end integrity protection for the resource. It would be simpler if the mirror resource were to provide a media type and copy the content directly.

chris-wood commented 6 months ago

The reason we chose BHTTP was to encapsulate the origin's response in its entirety down to the client, including the headers, as then clients have all possible information to make their consistency decisions.

martinthomson commented 6 months ago

So maybe I don't understand the proposal, but it doesn't really describe how this protocol is expected to integrate into an actual consistency scheme. Here was my understanding:

  1. Client obtains a URL for a resource and has secondary information that suggests that consistency and correctness is important for the resource.
  2. The client requests that resource.[^1]
  3. The client asks a mirror (or mirrors) using the protocol in this draft.

The direct request establishes correctness. The mirror requests establish consistency.

For consistency, it is true that resource metadata can alter the way in which content is interpreted. In theory at least, if you only ensure consistency of content, you might leave open the possibility of an attack. Polyglot formats are the most obvious way to have that happen, but that is very much more theory than practice. Altering processing logic based on the value of a header field happens, but it shouldn't be part of any design that relies on consistency. The only exception being content type.

The risks from altered header fields (or trailer fields...!) can be addressed by accepting a single format, or by only altering processing rules based on information that the mirror will supply.

Practically speaking, content type covers all cases I'm aware of. Indeed, the only case for which content type is relevant is making sure that you have a way to add new features to an existing protocol; and only when those features are not compatible with the existing format. That case also has other ramifications for consistency, meaning that in most cases a single format remains the best option all around.

The problem with getting all the headers is that you then have to embark on a game of determining which are relevant to the consistency game. Date? Probably not. Cache-Control? I suggest that it is better to just look at the content and maybe the content type.

[^1]: It might do so via an intermediary (OHTTP or MASQUE) to hide its identity, but a choice like that is largely orthogonal to the consistency question. I say "largely" because it make it harder for the server to use client identity as the basis for client-specific adaptations, which would undermine consistency.