Re: [Lurk] keeping private key private

Daniel Migault <daniel.migault@ericsson.com> Fri, 14 October 2016 18:52 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 3408112988B for <lurk@ietfa.amsl.com>; Fri, 14 Oct 2016 11:52:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxck5YR1fgMF for <lurk@ietfa.amsl.com>; Fri, 14 Oct 2016 11:52:29 -0700 (PDT)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 2218F12988A for <lurk@ietf.org>; Fri, 14 Oct 2016 11:52:29 -0700 (PDT)
Received: by mail-io0-x233.google.com with SMTP id j37so130674778ioo.3 for <lurk@ietf.org>; Fri, 14 Oct 2016 11:52:29 -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=CQGeU94NQRj5e4fUh+wEFzYvdh7tzGfrwruGemYo65k=; b=ssUQ3zVXMYyLDwX714LwencCBV9F2pRpprGuyfxQp84MF2tiumR2o+DJmnaRaEq5z4 EEH8Fv4JcTiaP83OChlGnye2YhOfuNM8UZA6EkEy7MVfRIPIfSIpjYl+rj9pJYS/GjPG Ph551XVUYiG58VB2W4axhXMUNJjVRUKUCi51eQ0Vd8A9BqXLcMtnZ0fSvVi6JQKI333H XZceBewXUWYiRBSVFKpvKW1iQ3mE/EIQA1/xHQ9bWM7Y/CvM41zbdVmHawbPnC4wmo7M AXqnLzxVQpz5UNaWMpvr4C2PkXL5lDD1PNomh7DzrhsKRsAv47hQmGRBErjxUptFCq2u vQfg==
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=CQGeU94NQRj5e4fUh+wEFzYvdh7tzGfrwruGemYo65k=; b=g0JEwq94gTw3PW4qEv8TBVpMvTWAboaq2DGJV2iWzDSn2/4VBJnpWAiNLmQCrpupNi xjsKhqyPq7k7lvAQ6AuoDvbIGrnWbiHVe3bSoGfEsA3buTkjDROsW06SaaPgZ0iStsUP nyEvx4NlqAzXuJFSN2DIIH36s9621PypiC0uuZIoseAkTo+eGzl1JARLLHrQIyB6LFK0 KN3bAalKbbPllJssh5hSowFIdKKKNpOKTsvURifN37XJB//mbZllvMe0H4Zby9uYXGvE 73nVSrc8ONrtCLcKpZ4TFiz+vts0kq7MpqKZ3WPRi6GvcREPiYEFF/2dcY4NEnhMcFdE lL9Q==
X-Gm-Message-State: AA6/9Rn11/pF8JCtCMno1/ui9rYGDgeJNzT418nz8Z68xYB9b91anBWH6fIh+AlKwdbnAMqAurSiS4dKdpCAAQ==
X-Received: by 10.107.28.148 with SMTP id c142mr12462278ioc.45.1476471148283; Fri, 14 Oct 2016 11:52:28 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.107.188.4 with HTTP; Fri, 14 Oct 2016 11:52:27 -0700 (PDT)
In-Reply-To: <87bmyputr3.fsf@alice.fifthhorseman.net>
References: <CADZyTk=+YjfZM_rMJtS=D0KNX3nbQ6jx91=F2VqQ_QR12a5foA@mail.gmail.com> <87bmyputr3.fsf@alice.fifthhorseman.net>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Fri, 14 Oct 2016 14:52:27 -0400
X-Google-Sender-Auth: WBG-JlOaXS0M2GyAdVYO2TF_KOc
Message-ID: <CADZyTkm1+=oE+DqgcAxy5CtaVLX0kxPA4sECjjaF-c0aZGhz6Q@mail.gmail.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Content-Type: multipart/alternative; boundary="001a113fd4b8508db2053ed7ba1e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lurk/CjsH_Dz3xQJwfxvLTRpuM1QLC1k>
Cc: lurk@ietf.org
Subject: Re: [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: Fri, 14 Oct 2016 18:52:33 -0000

Hi Daniel,

Thank you very much for the feed backs. I will try to clarify the problem
we are solving, expose why LURK in my opinion address this problem in a
"wise" way and expose why short term certificate (STC) does not solve this
problem.

Note that I am not opposed to STC, I think this is something good to be
done, however, it is complementary to LURK and not an alternative to.

The mail may be long, but feel free to split it into different threads. I
will be more than happy to clarify any aspects.

I agree with you that information delivered by a web site is what we must
be focused on and this is actually the goal of LURK* (in a TLS context).
Although the secret key material (SKM) and the information of a web site
are two different assets, they are not independent and protecting the
information requires the protection of the SKM. Information is
characterized at least by a content and an origin. An un-authenticated
content such as a software for example, does not have the same value if it
is being downloaded from the editing company or from public content sharing
site. The motivation of LURK is to provide the user the means to trust the
origin and as such the information delivered by the web site.

As a result, SKM must be protected as long as the information is delivered,
independently of the SKM characteristics which includes its life time.

I also clearly agree with you that protection of the SKM should be
performed with limited cost and as simple as possible.

It seems to me that LURK meet these criteria, which is the reason we would
like it to be standardized. As an observation, LURK like solution have been
deployed by CDN for example, and I believe their goals are not to consider
the most expensive and most complex solution. That said they might be other
and better solutions.
There has been some discussions on whether short term certificates (STC)
address the problem we want to solve that is either preventing the leak of
the SKM or in a TLS context providing means to trust the origin of the
information. In addition, there were also discussions on whether STC are
also less expensive and more salable than LURK. I disagree that STC is an
alternative to LURK.

    a) First STC does not address problem we are trying to solve, i.e
"ensuring the origin of the information". In that context, STC limits the
use of a SKM that leaks to a short period of time. The improvement over
long term certificate is only valid if leakage of the SKM only happen
accidentally - that is one time or when retrieving the SKM takes
significantly longer than the life time of the SKM. Such limitation to the
protections of the SKM are ways too narrow. SKM does not address for
example any attacks that can provide access to the SKM in an timely manner.
Such attacks simply needs to be re-done after any SKM renewal. Such attacks
includes for example privilege escalation vulnerabilities which there is
little ways to insure they will not happen. Heartbleed is typically an
existing attacks that only took an RTT to retrieve the SKM. STC does not
either address this attack - which we know exists - and may take years to
be disclosed. I see LURK ways more powerful as it address the root cause of
the problem instead of limiting the consequences of a leak. .

    b) Second, STC are really not inexpensive at all.
        b. 1) I might agree that generating a key is inexpensive. However
we should also consider that generating keys with a high randomness
frequently might not be as inexpensive as expected.
        b .2) That said certificates are not limited to key generation and
includes signing by the CA as well as revocation when needed. Even though
the cost of signing by the CA decreases, if the number of signing
operations increases in several order of magnitude, the overall cost may
not decrease. Especially the cost may remain significantly high for EV
certificates and for these certificates STC may happen to be very expensive.
        b. 3) STC as any certificate based solution does not provide
appropriated delegation mechanisms. As result, in a context of CDN, any
time the content owner changes the CDN a complex revocation procedure might
be required. Complexity may be due to the use of EV certificates as well as
the interrelations between the CDN and the content owner.

    c) Third, STC as certificate based solution considerably weaken the
security.
        c. 1) As certificates does not provide delegation mechanisms, the
delegation to a CDN often result in providing the SKM to a thrid party.
This goes against the principles of public cryptography, resulting in a
authentication that provides little benefit over self signed certificates.
        c. 2) EV may present delays that are non compatible with STC, as a
result, the use of STC in our context may be limited to DV certificates
which is the weakest certification level.

LURK instead
    a) solves the problem we are trying to solve as it prevents the leakage
of the key.
    b) is inexpensive as it does not affect the operations performed by the
CA. At least the cost remains the same as it is today. I think one reason
people see this solution as expensive is that most people think of the key
server as an HSM. HSM is probably an expensive alternative, but there also
less expensive alternatives that includes the use of open hardware security
modules [1], software implementation of the key server in which case the
cost is really the instantiation of the VM. This is typically less
expensive than the resulting operations, traffic from STC.
    c) is secure and with multiple level of security. The key server may be
only hosted by the content owner, provided to CDNs in different ways. Note
that providing an obfuscated key server (like an HSM) to the CDN still
provide more security than providing the key and limit the risk of leakage.
In addition by clearly splitting the SKM and session termination functions,
LURK  is likely to ease the deployment of TLS over CDNs and as result the
deployment of TLS.

I agree with you that having a key server adds an exchange between the
server terminating the TLS session and the key server which may result in
higher latency. The latency clearly depends on where the key server is
located. In case a high latency matters, the key server may be deployed
close to the terminating nodes. Of course there is a trade off between high
security requirements and low latency requirements. LURK makes this trade
off possible whereas certificates clearly prioritize the latency over
security. That said, the acceptable latency also depends on the information
delivered by the web site. Suppose the information is an update, latency
does not really matter, similarly if the content is a movie a additional .5
second might be acceptable too.

I do not really agree that LURK presents a scalability issue. I agree that
the model of LURK is more centralized that the model proposed by SFT,
similarly to what DNS is versus hostnames files. Of course the key server
needs to be deployed so that it serves the expected traffic, and a single
instance of key server may not be appropriated. On the other hand, by
centralizing the private key operations, it makes the deployment of a new
private key way easier. Only the key servers have to be provisioned with
the private key. Maybe we could also associate the key server with a
distribution of certificates which STC may designed. Again I do not see STF
are competing LURK but more complementing it.


BR,
Daniel


* For clarification let's call LURK the solution that consists in remotely
perform secret key operations.
[1] https://www.crowdsupply.com/cryptech/open-hardware-security-module


On Wed, Oct 12, 2016 at 5:45 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
wrote:

> Hi Daniel--
>
> On Wed 2016-10-12 13:10:04 -0400, Daniel Migault wrote:
>
> > 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.
>
> What's more important -- the secret key material, or the traffic and
> information on your website that it protects?
>
> When the certificate is long-lived, there are good arguments for the
> secret key being more valuable, because it can be misused in the future
> when we don't yet know what the value of of the traffic and information
> will be.
>
> It's also conceivable that a single cert (e.g. *.example.biz) could be
> more valuable than any one site it applies to.
>
> But when the certificate is short-lived and narrowly-scoped, the things
> the cert is trying to protect are proportionally more valuable, though,
> right?
>
> secret keys are cheap!  certificates are (increasingly) cheap!  Making
> cheap things less powerful and using them freely seems like a much
> simpler approach than trying to invest certificates with lots of power
> and then trying to find ways to avoid the misuse of that power.
>
> > 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.
>
> we have (a few) generic mechanisms already.  PKCS#11, as horrible as it
> is, provides for secret key isolation.  "PKCS#11-RPC" was floated as one
> idea in the LURK BoF, iirc, but i think it was (mostly) dismissed,
> though i don't remember why.
>
> But remote use of secret key material is also high-latency and prone to
> bottlenecks -- are these engineering costs worth the benefits?
>
> some people might amortize the costs of the high-latency handshake by
> establishing and encouraging the use of TLS sessions; this is in effect
> asking users to remember short-lived certs -- those sessions are going
> to still be valid authenticators (to those end users) even after the
> keyholder decides to rescind her grant of use of her secret key.
>
> So there are a set of tradeoffs involved, and it's not clear to me that
> the thing you're trying to protect is worth the energy and cost that
> would be invested here.  can you explain how you see those tradeoffs?
>
> All the best,
>
>       --dkg
>
> _______________________________________________
> Lurk mailing list
> Lurk@ietf.org
> https://www.ietf.org/mailman/listinfo/lurk
>
>