Re: [Lurk] Notes on preventing signing oracles

Daniel Migault <daniel.migault@ericsson.com> Mon, 24 October 2016 14:05 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: lurk@ietfa.amsl.com
Delivered-To: lurk@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF82B1296C1 for <lurk@ietfa.amsl.com>; Mon, 24 Oct 2016 07:05:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YO25EtpVOCX for <lurk@ietfa.amsl.com>; Mon, 24 Oct 2016 07:05:32 -0700 (PDT)
Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A84C129561 for <lurk@ietf.org>; Mon, 24 Oct 2016 07:05:32 -0700 (PDT)
Received: by mail-yb0-x22f.google.com with SMTP id f133so11831352ybc.3 for <lurk@ietf.org>; Mon, 24 Oct 2016 07:05:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zpUsOL34Bia9zKTipnQ+PIbLW1Vz3kErrhZQ2YP7qQk=; b=KPt+Y5/9FPeZDDrWxhO5acnq49Fo1hCqIp/JXrJbzBHBSuqEW+7FTab5Zc3yf89sgQ KdyqyLbPkCDxxH2SGos3mr2n1nYxglzcXst9iGj6A4qNtHnvy1QS9rezsmXp/bYDOYm7 yxfPgify71k0TMOFuaBT4HtpNVnMAFrAYlFd68O0Hhvc4eq5U+vjsOCBPQ/9LCD3p8Jp AB2JakUbSSxOEl2nOIUdKgsSfuZEFX6uWrsGQrKE7X9m9qVxl3j4bLmGgCINugirvAPW noN3biahFOTe6HKGNOmcDhX2i6x3chFqJP4X0RokLM2jfoq++b+2Ekdae9Z5XO91KfbM 6GrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=zpUsOL34Bia9zKTipnQ+PIbLW1Vz3kErrhZQ2YP7qQk=; b=NU+2WpR0y2cGpeIKB6WdgwHYomhYOUT5V/7Xb5g/+FFIMr0DD7A6NYIP1XNx7dRZDJ Xfm4aVk3wNVlCf+TnNEvrSxGolzR1sMN7tp3BQ8nr8NGlRQBqAcTrdV0FWm9nOXXidC1 azvzzzszW/vrRzioPfB/oNYEocQCUZT9fOfIEMTaiSCleSCTm0b4SlguPS/0qd+/RfrY 9SSyZHBFkYww5rraL7fAOp7Jg3PKOywD1wEFaJQOKYOw3Z/QdPZVOrsDC7LMnhJs9D4t Sm3+WMj3D6df7CA+CqnQ0BKsPk3+2J/5dLqpLn6OVGXyZHdpqPsEKqKyUa0MvuiS/jlb Rm4Q==
X-Gm-Message-State: ABUngvcC84lqhiyr6SD6QNofR3R7hI6kuIeQx44mBN8aD2uDARdVrdmsx4dq691vYCb03qxWS/IR/yj7c8DobA==
X-Received: by 10.36.74.205 with SMTP id k196mr2232774itb.101.1477317931277; Mon, 24 Oct 2016 07:05:31 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.107.188.4 with HTTP; Mon, 24 Oct 2016 07:05:30 -0700 (PDT)
In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C117F9AEEA@eusaamb107.ericsson.se>
References: <CABcZeBOs-oL_qYCBGkNX3z9zx9U=WzMSqdUpZG267J_0UL-ETg@mail.gmail.com> <CAJU8_nVj-R5sc505t8T6dqZMHNaAtqUifJY5ewOEmvBDUvzawQ@mail.gmail.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F9AEEA@eusaamb107.ericsson.se>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Mon, 24 Oct 2016 10:05:30 -0400
X-Google-Sender-Auth: NRZPPnGWjE5Dhlob4-MAGjaCsYc
Message-ID: <CADZyTknn58OViOviJh3EC_qndS39mHUgpz+h8r52L_tg9Nwn4A@mail.gmail.com>
To: Kyle Rose <krose@krose.org>, Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary=001a1140519483a293053f9ce293
Archived-At: <https://mailarchive.ietf.org/arch/msg/lurk/aEw2sS_aG_StNP75KnelZgVG4Lc>
Cc: LURK BoF <lurk@ietf.org>
Subject: Re: [Lurk] Notes on preventing signing oracles
X-BeenThere: lurk@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Limited Use of Remote Keys <lurk.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lurk>, <mailto:lurk-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lurk/>
List-Post: <mailto:lurk@ietf.org>
List-Help: <mailto:lurk-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lurk>, <mailto:lurk-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2016 14:05:37 -0000

Hi,

It seems the presented mechanism can be used to mitigate the signing oracle
issue. Unless someone opposes this I am encline to consider that the
signing oracle issue is closed.

BR,
Daniel

On Wed, Oct 12, 2016 at 11:00 AM, Daniel Migault <
daniel.migault@ericsson.com> wrote:

> Hi,
>
>
>
> 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. **
>
> Let
>
> t = cb + r
>
> and
>
> 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.
>
>
>
>
>
> BR,
>
> Daniel
>
> *From:* Lurk [mailto:lurk-bounces@ietf.org] *On Behalf Of *Kyle Rose
> *Sent:* Monday, July 18, 2016 11:23 AM
> *To:* Eric Rescorla <ekr@rtfm.com>
> *Cc:* LURK BoF <lurk@ietf.org>
> *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.
>
> Kyle
>
>
>
> On Mon, Jul 18, 2016 at 9:22 AM, Eric Rescorla <ekr@rtfm.com> 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
>
> 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.
>
>
>
>
> _______________________________________________
> Lurk mailing list
> Lurk@ietf.org
> https://www.ietf.org/mailman/listinfo/lurk
>
>
>
> _______________________________________________
> Lurk mailing list
> Lurk@ietf.org
> https://www.ietf.org/mailman/listinfo/lurk
>
>