Format for server key information

[martinthomson]

Right now we just use words for this, but we might want to define a format that includes keyID, KEM, KDF, AEAD, and pk for the server. A media type for this might be good. Given the general applicability of this, it might want to be a separate document.

[ekr]

I would suggest we steal either the MLS or the ECH format.

On Tue, Jan 19, 2021 at 2:14 AM Martin Thomson notifications@github.com wrote:

Right now we just use words for this, but we might want to define a format that includes keyID, KEM, KDF, AEAD, and pk for the server. A media type for this might be good. Given the general applicability of this, it might want to be a separate document.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/unicorn-wg/oblivious-http/issues/16, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIPLIKWUAMCATTJF2WJ4S3S2VLRBANCNFSM4WIRJ2YA .

[martinthomson]

That seems ideal. I was more thinking about how we might represent this information as a media type or in a header field. Right now, we're assuming configuration rather than discovery, but for things like key rotation, it could be helpful to include a way to provide updated keys.

One way this might help to provide a way for an oblivious request resource to indicate some of the keys that can be used to talk to it.

[martinthomson]

I looked at the ECH format and it wasn't suitable. It doesn't include a key identifier (it uses that hashing thing for identification) and it relies on TLS signaling the KDF and AEAD that was chosen. It also includes stuff we don't need.

The MLS KeyPackage is even more divergent from our needs. MLS remaps the KEM, KDF, and AEAD identifiers and includes a bunch of other stuff we don't need.

What I've implemented, which can easily change is this:

Config {
  Key ID Length (i),
  Key ID (..),
  KEM (16),
  KDF (16),
  AEAD (16),
  Public Key (..), # remainder
}

However, I think that it makes sense to have a format that wraps multiple keys, say:

Prefixed Config {
  Config Length (i),
  Config (..),
}
Oblivious Request Resource Config {
  PrefixedConfig (..) ...,
}

This would allow an oblivious request resource to advertise multiple keys.

Drawbacks:

• This is not space efficient: if the same key supports multiple configurations, then this will require that the key be repeated multiple times, and with a different key identifier for each. But I'm going to suggest that gzip can solve that problem for us.

• There is no way to annotate individual keys. This might complicate the addition of per-key expiration times. My initial view is that once replacement keys are available, you don't need to advertise other keys, even if you still accept requests for some time.

All told, this is starting to smell like a substantial enough piece to warrant a separate document.

[ekr]

Hmm... I'm not sure I agree with this analysis. This seems to me that it's isomorphic to the ECH situation, you're just making a different design tradeoff about where to carry the KDF and AEAD, for instance. What stops you from using the hashing thing and carrying the KDF and AEAD in this brand new format?

On Wed, Jan 20, 2021 at 4:16 PM Martin Thomson notifications@github.com wrote:

I looked at the ECH format and it wasn't suitable. It doesn't include a key identifier (it uses that hashing thing for identification) and it relies on TLS signaling the KDF and AEAD that was chosen. It also includes stuff we don't need.

The MLS KeyPackage is even more divergent from our needs. MLS remaps the KEM, KDF, and AEAD identifiers and includes a bunch of other stuff we don't need.

What I've implemented, which can easily change is this:

Config { Key ID Length (i), Key ID (..), KEM (16), KDF (16), AEAD (16), Public Key (..), # remainder }

However, I think that it makes sense to have a format that wraps multiple keys, say:

Prefixed Config { Config Length (i), Config (..), } Oblivious Request Resource Config { PrefixedConfig (..) ..., }

This would allow an oblivious request resource to advertise multiple keys.

Drawbacks:

-

This is not space efficient: if the same key supports multiple configurations, then this will require that the key be repeated multiple times, and with a different key identifier for each. But I'm going to suggest that gzip can solve that problem for us.

There is no way to annotate individual keys. This might complicate the addition of per-key expiration times. My initial view is that once replacement keys are available, you don't need to advertise other keys, even if you still accept requests for some time.

All told, this is starting to smell like a substantial enough piece to warrant a separate document.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/unicorn-wg/oblivious-http/issues/16#issuecomment-764059399, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIPLIL25D37MHIJ254FSHLS25W4FANCNFSM4WIRJ2YA .

[martinthomson]

OK, I'm going to try not to react here with how abhorrent the hashing thing is, but I think that it exists primarily to avoid carrying information in the ECH context.

We could carry certainly carry KDF and AEAD identifiers separate to the key identifier. That's a choice that would allow us to reuse the part of the ECH configuration that repeats that piece. And have multiple combinations of those for the same key identifier. I don't care so much about that piece, though in practice you can get that by packing those fields into the key identifier.

The pieces we really don't want are the public name (which means nothing in this context) and extensions. This is not something that needs extending arbitrarily.

[ekr]

On Wed, Jan 20, 2021 at 4:33 PM Martin Thomson notifications@github.com wrote:

OK, I'm going to try not to react here with how abhorrent the hashing thing is, but I think that it exists primarily to avoid carrying information in the ECH context.

We could carry certainly carry KDF and AEAD identifiers separate to the key identifier. That's a choice that would allow us to reuse the part of the ECH configuration that repeats that piece. And have multiple combinations of those for the same key identifier. I don't care so much about that piece, though in practice you can get that by packing those fields into the key identifier.

My point is that the design considerations are no different here than for ECH. As far as I can tell, this simply reflects a different aesthetic preference. That's fine, but I think consistency of design is useful and important, and so to the extent to which it's just aesthetics we should come down to one conclusion and then impose it on both. If that means changing ECH, then so be it.

The pieces we really don't want are the public name (which means nothing in this context)

I agree with this.

and extensions. This is not something that needs extending arbitrarily.

I don't agree with this. My experience is that more or less whenever we make the decision not to leave ourselves extension points we find that we regret this. In that vein, it's worth noting that we can address the public name issue by making public name an extension, thus harmonizing the formats and avoiding the clutter here.

[martinthomson]

I value reuse, but not to that extent. Not when it means a format that has extensions, where in one context extension A is mandatory, but in another context extension B is mandatory instead. And all the mess that comes with extension processing to boot.

[martinthomson]

Oh, and this point:

My experience is that more or less whenever we make the decision not to leave ourselves extension points we find that we regret this.

I would expect to be able to use a different extension point at the next layer up. That is, define a new media type or whatever.

[chris-wood]

For what it's worth, I would like for ECH and OHTTP to share the same shape of configuration, modulo the unnecessary bits (public name). @martinthomson, can you elaborate on why the client-computed Key ID is, well, abhorrent? :-)

[ekr]

While I don't agree with MT about extensions, perhaps we could factor out the common pieces into a component that could be used by both ECH and OHTTP could use -- and maybe even MLS.

On Thu, Jan 21, 2021 at 8:59 AM Christopher Wood notifications@github.com wrote:

For what it's worth, I would like for ECH and OHTTP to share the same shape of configuration, modulo the unnecessary bits (public name). @martinthomson https://github.com/martinthomson, can you elaborate on why the client-computed Key ID is, well, abhorrent? :-)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/unicorn-wg/oblivious-http/issues/16#issuecomment-764792760, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIPLIO53S22RAQSMK4SYRDS3BMQLANCNFSM4WIRJ2YA .

[chris-wood]

So, a server-chosen key ID does seem attractive, for a number of reasons:

• Deployment-specific flexibility in the ID -> key mapping
• Avoids hash computation (and algorithm choice) on clients

However, for the sake of exploration, let's say a server wants to publish two configs -- one for AES and another for ChaCha. Clients would obtain this set of of configs... somehow... and make a choice between the two based on their preferences (do they support AES intrinsics?). Let's say an attacker stripped the config with AES from the response to client, forcing it to use ChaCha. The client's Key ID signal does not indicate to the server that the chosen key was made from an incomplete view of the keys. Is this a problem? Perhaps not for AEAD algorithms we care about, but what about in a future world where one key carries a PQ KEM public key and another carries a classical KEM public key?

If we think KEM key selection is a problem, then it seems there are a couple ways to address this:

1. Have clients signal to servers their view of the config set (as is done in ECH with the config_id being computed as a hash of the ECHConfig)
2. Ensure attackers can't interfere with client view of configs

If OHTTP configs are published in DNS (I'm not necessarily advocating for this), then (1) seems preferable. If OHTTP configs are fetched directly from the request resource, then perhaps (2) applies?

I guess the representation of the key ID depends on the threat model, which isn't surprising. :-)

@ekr, what do you think?

[ekr]

I spent some time looking back at the history of ECH. It turns out that I originally had a key id and then Kazuho proposed removing it, mostly on the grounds that it was easier to manage with a unique value. It seems like the situation is basically the same here for O-HTTP as for ECH, so we should converge on a common answer whatever that is.

https://github.com/tlswg/draft-ietf-tls-esni/pull/43

WRT the question of negotiation, ISTM that that's a function of folding the entire configuration into the transcript, and so obviously another identifier is needed if you want to refer to a specific component in the configuration, whether that's a key or a config instance or whatever.

[chris-wood]

WRT the question of negotiation, ISTM that that's a function of folding the entire configuration into the transcript, and so obviously another identifier is needed if you want to refer to a specific component in the configuration, whether that's a key or a config instance or whatever.

To clarify, are you suggesting possibly folding the entire config set into the transcript and then identifying one specific config in that set (via key id)?

[ekr]

If you're concerned about downgrade, I think it's the only way. Though of course at that point the client has already sent the information, so the value is limited.

On Thu, Jan 21, 2021 at 1:54 PM Christopher Wood notifications@github.com wrote:

WRT the question of negotiation, ISTM that that's a function of folding the entire configuration into the transcript, and so obviously another identifier is needed if you want to refer to a specific component in the configuration, whether that's a key or a config instance or whatever.

To clarify, are you suggesting possibly folding the entire config set into the transcript and then identifying one specific config in that set (via key id)?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/unicorn-wg/oblivious-http/issues/16#issuecomment-764965967, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIPLIO7HC7LXZ25IM3NJQ3S3CPBVANCNFSM4WIRJ2YA .

[chris-wood]

Yeah, that's a good point. So perhaps there's not much we can do about downgrade other than ensure integrity for the config set?

[martinthomson]

Documented the agreed format in #24. We've still open questions about the extent to which this and ECH can be harmonized, so I'll open a separate issue to ensure that happens.

[martinthomson]

Let's leave #27 as where we can track key format changes.