Re: [Lurk] Notes on preventing signing oracles

Kyle Rose <krose@krose.org> Mon, 18 July 2016 15:36 UTC

Return-Path: <krose@krose.org>
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 90CC712DB8D for <lurk@ietfa.amsl.com>; Mon, 18 Jul 2016 08:36:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 wgwMjB2cXJHr for <lurk@ietfa.amsl.com>; Mon, 18 Jul 2016 08:36:32 -0700 (PDT)
Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 26AFE12DBF3 for <lurk@ietf.org>; Mon, 18 Jul 2016 08:22:38 -0700 (PDT)
Received: by mail-qk0-x235.google.com with SMTP id p74so160024860qka.0 for <lurk@ietf.org>; Mon, 18 Jul 2016 08:22:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k8/ahQG59Z0vlHGgt0u6BJA7grfvaxm58Aj7HxE4/Ag=; b=J8TzSCZPZMpjMXVFIe+UYyjCjJcFc8neB7GQ06wJWDtLXBpeyeBe6OEAPP0JG0QQyT eAT+FIa1JaYlXV1GM2b1zvbmksslc7Jjplc8IzFUfVgV8gW83Plk04XnVgbwrHEL6C0a meqVLIi1ursaIedJtuvte+MFer/T3+n6o4bhk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k8/ahQG59Z0vlHGgt0u6BJA7grfvaxm58Aj7HxE4/Ag=; b=b2bRtBHX4wBw9hzf6T0+VFkYYu7rpELAOlq+8+0lVkgZS+q+PkFD7/BaxVy8EmIXpa dQr1f7oYpEbojIRLohtzejefp2gDNk7ahhODYu26ehBItJjMSSYCFCVnGOMP0VpVSrsI 54USpCH18rYoyPU4/S380vQ3n7Hi6qnreLEU7pqhW5dMuJ7iek8FdDpnfEo0CcP/buy8 ADUARogJ/rBHbBPjBxUOCVngNkBOwWB/ljAewRH/H4x9LpIJuFXPCWTW5+FC3iN8fJS6 Mu4128JYK08VTwXwvex20ykT97gOAWSDMrBDX8/3E1IfQe/eguKkUMV4vG/f+sBT6+yl h/eQ==
X-Gm-Message-State: ALyK8tJcup+yLA5OUMaZ7meBLOsSJy7PPy7mNippAhSOh+bRrwxUpQKnuCkZMbU4xe+dqjalqoHKvdg4AHrJbA==
X-Received: by 10.55.18.86 with SMTP id c83mr47582319qkh.187.1468855357252; Mon, 18 Jul 2016 08:22:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.118.135 with HTTP; Mon, 18 Jul 2016 08:22:36 -0700 (PDT)
X-Originating-IP: [31.133.178.3]
In-Reply-To: <CABcZeBOs-oL_qYCBGkNX3z9zx9U=WzMSqdUpZG267J_0UL-ETg@mail.gmail.com>
References: <CABcZeBOs-oL_qYCBGkNX3z9zx9U=WzMSqdUpZG267J_0UL-ETg@mail.gmail.com>
From: Kyle Rose <krose@krose.org>
Date: Mon, 18 Jul 2016 17:22:36 +0200
Message-ID: <CAJU8_nVj-R5sc505t8T6dqZMHNaAtqUifJY5ewOEmvBDUvzawQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary=001a11475356cbba140537ea8919
Archived-At: <https://mailarchive.ietf.org/arch/msg/lurk/TI7RdMqype9oxI1Cl8_6U9kOUqI>
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, 18 Jul 2016 15:36:34 -0000

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
>
>