[Lurk] keeping private key private

Daniel Migault <daniel.migault@ericsson.com> Wed, 12 October 2016 17:10 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: lurk@ietfa.amsl.com
Delivered-To: lurk@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2F39C129622 for <lurk@ietfa.amsl.com>; Wed, 12 Oct 2016 10:10:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Status: No, score=-2.597 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_LOW=-0.7, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Ock1yM-7kDSS for <lurk@ietfa.amsl.com>; Wed, 12 Oct 2016 10:10:06 -0700 (PDT)
Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 3F25D1294AA for <lurk@ietf.org>; Wed, 12 Oct 2016 10:10:06 -0700 (PDT)
Received: by mail-it0-x235.google.com with SMTP id o19so60727821ito.1 for <lurk@ietf.org>; Wed, 12 Oct 2016 10:10:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=x6dJ9mNKeQeAbeWyTLW32AaUwTsGaZYqqOaIoUFnW54=; b=BhWXmpMqe0f6flCuugCqjm7am6zIf5H3pyEnu72lz3vazSKEFXMXpGgAYmRylq+iKd elvZ1PfupjyODsKTCPJBJt4d9tPeZcFwfkf2E7kE+lL8mgZIryrDaFBtjxcH0yxLKUMu F0oX8V7mqV8QmBifSCGyaBQ5vTdhA4ViDvb5lGPZ6V9l1as+/PeKFY6v/d6MXpvS6rvR kECTx5BuGn2bBUwX7qQ0qehhU/Mkzw2H/Es22ccsCJW8gI6KGg4SO7iEqotEtimQGn37 WW01XLkRnzC0Cb/HICdt+ILaR35q0eFX8AH8d0G6i68EWYEkXficEY4eugxQEaaoBKl+ ObUA==
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:from:date:message-id:subject :to; bh=x6dJ9mNKeQeAbeWyTLW32AaUwTsGaZYqqOaIoUFnW54=; b=VPup2b0b9h5ty9UCmX07dgM2DiZyao5iiI1XaIPQpQziQ+CqcAH/zo/4UESie9NwRM 94j9dNyEHhk0OOzZncCWXULYUUXlgqHenNLYXl2P2sZ5IPX1AKoY0Pba71MnKfUli3Q0 zOR4RuNkRyIXhQXQ3zN+b4IfbRqtJmGKMhGc+L1uPzefjOnxIDGAw+1zE/QgpHrbpG7N Hex6B8uomCRQQTL+kL/QGkVihaU9Od9WPeJgPTNtGpCBffyNY/WmigMj7ilmJ3LI8Es/ nGsJlDD5bjt/PC7JapD5WUtnigiv71/k9IavynpnCK64EPQGTAoQrFlL86fJH49moFSR JBGQ==
X-Gm-Message-State: AA6/9RkINuD2C7QsvXTm8gEKkINCcrN1Jv5Ao1cNgUeLr6zLhWKdUhR7w2d/y21tLRpKFFGLIVfcW9ZU/YM+oA==
X-Received: by with SMTP id k10mr3563613ith.120.1476292205448; Wed, 12 Oct 2016 10:10:05 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by with HTTP; Wed, 12 Oct 2016 10:10:04 -0700 (PDT)
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Wed, 12 Oct 2016 13:10:04 -0400
X-Google-Sender-Auth: LcKoLCyB8rWw-fVIMZbx0of4Tys
Message-ID: <CADZyTk=+YjfZM_rMJtS=D0KNX3nbQ6jx91=F2VqQ_QR12a5foA@mail.gmail.com>
To: lurk@ietf.org
Content-Type: multipart/alternative; boundary=94eb2c0359427d9d02053eae108e
Archived-At: <https://mailarchive.ietf.org/arch/msg/lurk/KsXe7SdpfK2IWaVYyS8GNhkWtgM>
Subject: [Lurk] keeping private key private
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: Wed, 12 Oct 2016 17:10:08 -0000


Following the discussions of the BoF in Berlin, I agree that the generic
principle for all TLS use cases mentioned in the BoF can be designated as
providing means to delegate TLS authentication.

Currently delegating a TLS service to a third party or multiple edge nodes
is mostly based on distributing the full private key to multiple edge nodes
that may even be in a different domain. Such a distribution prevents the
key owner to keep the control of the private key as well as to prevent the
key to leak. For example, with LURK, the Heartbleed attack would have had
very limited impact as the private key would not have been hosted on the
edge server. By design, LURK would have prevented the key to leak.

The short term certificate is for sure a useful mechanism, but the
mechanism does not prevent the leakage of the private key. Instead it
limits the use of a private key to a shorter period. This may be useful as
long as the time to retrieve the private key is longer than the life time
of the certificate which was not the case in the case of the Heartbleed

My understanding is that there are currently no mechanisms that prevent the
keys to leak in the case of TLS. There is a huge demand from the industry
to provide mechanisms that protects the private key from leakage. The
reason we focused on TLS is that by limiting the use of a single protocol
it provides more control on the usage of the key. However, the protection
of the private key can also be handled in a more generic way outside the
scope of TLS.  I would like to understand whether mechanisms to prevent
leakage of the private key should not be handled in the context of TLS and
instead being handled in a more generic way.