Re: [Lurk] Notes on preventing signing oracles

Daniel Migault <> Wed, 12 October 2016 15:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9491129759 for <>; Wed, 12 Oct 2016 08:00:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9RuKF5I_a7uX for <>; Wed, 12 Oct 2016 08:00:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B1B8D129688 for <>; Wed, 12 Oct 2016 08:00:36 -0700 (PDT)
X-AuditID: c618062d-743ff700000009b8-5f-57fe53153eb9
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 7B.FE.02488.5135EF75; Wed, 12 Oct 2016 17:13:27 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Wed, 12 Oct 2016 11:00:34 -0400
From: Daniel Migault <>
To: Kyle Rose <>, Eric Rescorla <>
Thread-Topic: [Lurk] Notes on preventing signing oracles
Thread-Index: AQHR4MU/DpBLReS1u0mx+algo27MpaAekfAAgIbFEdA=
Date: Wed, 12 Oct 2016 15:00:34 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C117F9AEEAeusaamb107erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZXLonRFc8+F+4Qft1XosVr8+xW6x/MYnN 4u0aPwdmjyVLfjJ5dF38zuQx+XEbcwBzFJdNSmpOZllqkb5dAlfGhAlHmQuWHWGqWLh7MnsD 44vdTF2MnBwSAiYSM8/PZeti5OIQEtjAKHHk/RkmCGc5o8TGQ9NZQKrYBIwk2g71s4PYIgK2 EifPzmEDsZkFZCS6b7WA1QgLmEs83PmetYuRA6jGQuLrQg+IciuJfQ2XmUHCLAKqEhevhYOE eQV8JSY2drNArJrOKHH+yCYWkBpOgUCJni/xIDWMAmIS30+tYYLYJC5x68l8qJsFJJbsOc8M YYtKvHz8jxXCVpKY8/oa2CpmgXyJzb8CIFYJSpyc+YRlAqPILCSTZiFUzUJSBRHWlFi/Sx+i WlFiSvdDdghbQ6J1zlx2ZPEFjOyrGDlKiwtyctONDDYxAmPpmASb7g7G+9M9DzEKcDAq8fAu 0PgbLsSaWFZcmXuIUYKDWUmEl9f7X7gQb0piZVVqUX58UWlOavEhRmkOFiVx3rjV98OFBNIT S1KzU1MLUotgskwcnFINjBurtsZL155wM8ipO9r4Q+zAPe0UabsALk9lw7PCD1ubd2T35FZu fKHVbRGg9yhgW83Zrcc5rix9bxb9bcGZnt+JH45PeG7QP/fC3keFeRNcdfbP/1GbukjAM42f y/e5+375O6bz2xItH32M33hI/6P5UbtEO4mHIT9Sc08bK2XIHMx7Er2hWYmlOCPRUIu5qDgR ANDm1EGhAgAA
Archived-At: <>
Cc: LURK BoF <>
Subject: Re: [Lurk] Notes on preventing signing oracles
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Limited Use of Remote Keys <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Oct 2016 15:00:40 -0000


If I understand correctly, to prevent a generic signing oracle, some mechanisms or operations should be defined so the signed public key can be believed to be part of legitimate ECDHE exchange instead of some random data. This includes checking the public key belongs to the curve or proving that the Edge Server owns the corresponding private key associate to that curve.

In order, for the Edge Server, to prove the ownership of the corresponding private key, I propose the following mechanism. Please let me know if you agree with that mechanism as well as if you believe the generic signing oracle has been sufficiently addressed.

Upon the request the server computes:

a)       r a randomly generated number the Edge Server can chose

b)      c a randomly generated number the Edge Server cannot chose. **
t = cb + r
bG the public key to be signed.

The Edge Server sends to the Key Server:
rG, tG, c,  bG

The Key Server checks: c(bG) + rG = tG

** Ideally, the number could be provided by the Key Server for each request. However, we can probably find some reasonable alternatives where the number is generated by the Edge Server while being reasonably out of control from the Edge Server. For example we could use the resulting hash of a combination of a shared secret between the Edge Server and the Key Server,  associated to a sequence number address. There are probably other maybe better ways to do and feel free to propose alternatives.

From: Lurk [] On Behalf Of Kyle Rose
Sent: Monday, July 18, 2016 11:23 AM
To: Eric Rescorla <>
Cc: LURK BoF <>
Subject: Re: [Lurk] Notes on preventing signing oracles

It's possible we can't do much to prevent creating a generic signing oracle for TLS 1.2, but for 1.3 we can send precursors to the key owner and require it to reproduce the final input to the signature algorithm, constraining the adversary to signatures of messages of the form (0x20){32}("TLS 1.3, (server|client) CertificateVerify")(0x00)(.){64} for SHA-256.

We could potentially backtrack even further, sending inputs to each of the hashes and requiring the key owner to do additional verification, at the risk of exposing some data to the key owner that we might not want to.
Is this worth the added complexity and duplicated effort (by both the server and the key owner)? Regardless of best-practice, since it's at least somewhat likely that a particular signing key will be used in more than context, this might prevent some future class of cross-protocol attacks.

On Mon, Jul 18, 2016 at 9:22 AM, Eric Rescorla <<>> wrote:
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


[1] I'm ignoring the length bytes for the purposes of this discussion.

Lurk mailing list<>