[Lurk] Notes on preventing signing oracles

[Eric Rescorla <[e-mail]>]

The current charter proposal says:

  A Standards Track document that defines the interface between an edge
  server and a content owner. Security is a key concern, specifically
  avoiding a "signing oracle" where possible.

This text is a bit unclear, but I presume that the intent is to avoid
allowing the Server to use the KeyOwner as a signing oracle. This
message attempts to explore how hard this is.


As I think is well known, TLS 1.2 servers inherently allow clients to
obtain a signature with the server key on a message with a 32-byte
prefix chosen by the client [0]. In a LURK context, if one adopts the
naive design where the Server supplies the ServerKeyExchange to the
KeyOwner, the Server can obtain a signature by the KeyOwner on a
string which consists of:

- 32 bytes of ClientRandom (which can be chosen by the Server)
- 32 bytes of ServerRandom (which in the worst-case for the attacker
  is selected by the KeyOwner)
- The serialization of the ServerKeyExchange message which ostensibly
  consists of [1]:
  - The server's ECDHE share
  - The server's FFDHE group + share

It should be clear that if we just allow the Server to supply an
unverified key/share that that's a very powerful signing oracle, but
there are also limits to how much the KeyOwner can validate the share:

- If it's ECDHE (NIST curves) then it can validate that the ostensible
  point is on the curve. This allows the Server to generate a pretty
  random x-coord value but then y-coord has to match (assuming we
  require uncompressed points).

- If it's ECDHE (CFRG curves), then the Server can basically generate
  an arbitrary 32 or 48-byte string

- If it's FFDHE, then the Server gets to control a huge amount of data
  if you allow custom groups, but one could require that Servers use
  the defined FFDHE groups, in which case, the Server just gets to
  specify Y as a random value.

Maybe one could do a bit better than this with some more thought, but
I suspect that ultimately really preventing a signing oracle requires
preventing the Server from arbitrarily choosing the "public" part of
the DH share, e.g., by requiring the Server prove it knows the private
part) Absent this, I'm not sure how much security value this actually
provides over no validation (the CFRG curve case seems especially
bad).

-Ekr


[0] https://tlswg.github.io/tls13-spec/#rfc.section.4.3.2
[1] I'm ignoring the length bytes for the purposes of this discussion.