[Lurk] Notes on preventing signing oracles
Eric Rescorla <ekr@rtfm.com> Mon, 18 July 2016 07:23 UTC
Return-Path: <ekr@rtfm.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 B511712D0D3 for <lurk@ietfa.amsl.com>; Mon, 18 Jul 2016 00:23:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 QcYED_w0EWwf for <lurk@ietfa.amsl.com>; Mon, 18 Jul 2016 00:23:06 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 D943F12D14D for <lurk@ietf.org>; Mon, 18 Jul 2016 00:23:05 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id l125so152327630ywb.2 for <lurk@ietf.org>; Mon, 18 Jul 2016 00:23:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Pi64hE8RCn1NBAlfjeb2lAnqw34jIU8q4Lrq9MCmqgw=; b=AN7RY+Zi+dZlkMFRGisgMD3LJjEIyjrErki9D00MAQxjlJDVMrfd++XVk0ptIPOzLV epUukCiPmzmQxSHpR8MZoSjICxzC3oZmhrNZQbMwfBjaS6cCnj1cNr4Y9zS1su0eBHMl TS7/uk2HdJ9lAr74MxpHNMJ6s3VKDiojl7dfC/GEbyN6vGkU4KAoRH3FBWjWNEjoc6KO UKOAIXympz6mzsTjntm4ANGoJQuVp1FdwTK1ubwVycdUv9Ra6YK82wqMejHZ/o13Ys0R ScxwOA+uDwMJpE7f/D/q40eO5vcpknV7VCAiaMNIOnNIzDbakjANW2Uo9lkdbUL0HC+2 RVLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Pi64hE8RCn1NBAlfjeb2lAnqw34jIU8q4Lrq9MCmqgw=; b=QZIqO4aiuu1d0jbNDFw9AijFCElA688qjmHsykw0bn6Tfxlkkw6yriy1LdKnSAb05F PiKL1yD3LVbdi7qJNWP/dZbj7qaZIykRalwYumtLXi93+VMf7EgHB2qYBn15uwmQxXhW oC/4R7e3Oa3rw1ZNU3CRuywmhRIpCZOVTf8ASpSmXHP2UNS49vTHH1DkCBl0Qo3sQL9K u3d2wTG2stnx9GL3/DbgUqHwweYwHks5pypTKqp+Jec/ccRphxrs73PrRaN+56upG+0p OLuGa/OGl594VAIepsQkCWTVpS0LX1LFyrgJV9OV2LrlSWMOrikMlx2rJ2E6B11fZDGy oMsg==
X-Gm-Message-State: ALyK8tJJptd58sNx3a4bBNDWwxwABwqajltMpq0rz2mMKgbXt35GxRF6DxqcIaVxxKgE9uR0ybG2E4AqdxRcHA==
X-Received: by 10.129.125.135 with SMTP id y129mr23519245ywc.107.1468826584540; Mon, 18 Jul 2016 00:23:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.152.13 with HTTP; Mon, 18 Jul 2016 00:22:25 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 18 Jul 2016 09:22:25 +0200
Message-ID: <CABcZeBOs-oL_qYCBGkNX3z9zx9U=WzMSqdUpZG267J_0UL-ETg@mail.gmail.com>
To: LURK BoF <lurk@ietf.org>
Content-Type: multipart/alternative; boundary="001a11492ce8cf10830537e3d6ba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lurk/izHFUkyr8XusOLrB9ZXMq_3G1BY>
Subject: [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 07:23:08 -0000
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.
- Re: [Lurk] Notes on preventing signing oracles Kyle Rose
- [Lurk] Notes on preventing signing oracles Eric Rescorla
- Re: [Lurk] Notes on preventing signing oracles Daniel Migault
- Re: [Lurk] Notes on preventing signing oracles Daniel Migault