Re: [therightkey] [pkix] Proposal for working on PKIX revocation open issues
Phillip Hallam-Baker <phill@hallambaker.com> Sat, 15 November 2014 21:56 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: therightkey@ietfa.amsl.com
Delivered-To: therightkey@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722EB1A8879 for <therightkey@ietfa.amsl.com>; Sat, 15 Nov 2014 13:56:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.621
X-Spam-Level:
X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 NdJL7SpFewPH for <therightkey@ietfa.amsl.com>; Sat, 15 Nov 2014 13:56:55 -0800 (PST)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D816C1A8872 for <therightkey@ietf.org>; Sat, 15 Nov 2014 13:56:54 -0800 (PST)
Received: by mail-la0-f53.google.com with SMTP id mc6so16849009lab.12 for <therightkey@ietf.org>; Sat, 15 Nov 2014 13:56:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=/0Yvo167k0TccamqEgaRMBBaZ09SjtLC52oSOkdaWLg=; b=on2tSMN2XO+oUyte2TdNnrOPkLhO9UU0+DuLHlAKA867b5N/vkveyD0GITEv5Vcy2P etx0bv5ZpH72IslPgwqBMorzzpKSHJDcM9HluJQ8BkupGijfKO6Zfvev+jfGXJ9pl17s Oyc4PO5C+5ofLNyEt1CDGJUIbZtOmi9FYqlyF2CgRPgAKrT20Es2PgNsIXKm4FyO5lDE jrkvC0VNXiC7kf8uxeiAjafq1VRj/6iv1/B/1We6YNBWnq0BnEtqRrwAQCrzqcKfzYjL BcIJu/quD7OjlTjV7FL8k1ktW9i2YU2ZUXMZpWbbn6UVeG4B7+Y2DcGT12pwchkit/5l E8Kg==
MIME-Version: 1.0
X-Received: by 10.152.2.41 with SMTP id 9mr15572028lar.47.1416088613375; Sat, 15 Nov 2014 13:56:53 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.34.212 with HTTP; Sat, 15 Nov 2014 13:56:53 -0800 (PST)
In-Reply-To: <5466AF87.2050307@gmail.com>
References: <5466AF87.2050307@gmail.com>
Date: Sat, 15 Nov 2014 16:56:53 -0500
X-Google-Sender-Auth: 7oNQC_UpMlUAHkOXSfFcIG6R5zw
Message-ID: <CAMm+Lwg30tb+yFxVMG3qJ=_fjVT=ASqUmaf9gH8wpUhUGxgf6A@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: "therightkey@ietf.org" <therightkey@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/YHK8JDyRrDGPiYx4rEJQoAHMYGo
Subject: Re: [therightkey] [pkix] Proposal for working on PKIX revocation open issues
X-BeenThere: therightkey@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <therightkey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/therightkey>, <mailto:therightkey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/therightkey/>
List-Post: <mailto:therightkey@ietf.org>
List-Help: <mailto:therightkey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/therightkey>, <mailto:therightkey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Nov 2014 21:56:57 -0000
On Fri, Nov 14, 2014 at 8:42 PM, Dr. Massimiliano Pala <massimiliano.pala@gmail.com> wrote: > Dear PKIX Enthusiasts, > For example, current specifications about OCSP stapling do not address the > case of client authentication (which is a widespread use case outside the > web environment) or, again, defining some new transport protocols for > delivering OCSP responses which might reduce operational costs for > revocation service providers. > After proposing the idea to Stephen Farrell and Kathleen Moriarty, we would > like to know if there might be interests in participating in updating the > status of the current revocation mechanisms for PKIX. This said, the scope > of the work I am proposing is very limited. Specifically: > > (a) Defining new transport protocols for revocation information availability > (e.g., OCSP over DNS or OCSP over LDAP) There is already a mechanism for transporting certs over LDAP. I am pretty sure the folk who do that sort of thing have done the OCSP in LDAP thing already. I don't see a future for LDAP as an Internet protocol though. LDAP introduces a completely gratuitous name infrastructure (X.500) that adds no value other than to the consultants who can spin a 3 week consulting gig bikeshedding the DIT with the customer. Nobody has ever explained an advantage to me of LDAP over HTTP and a well-known service convention. OCSP over DNS has the attraction that DNS transport is fast. But remember that DNS transport is fast because it is absolutely minimal. Putting more stuff into DNS risks making it slow. The construction of PRIVATE-DNS attempts to square this circle by providing a mechanism that allows other protocols to make use of the DNS channel (if that makes sense) without incorporating them into the DNS protocol. > (b) (Possibly) defining a more lightweight revocation mechanisms (e.g. > Lightweight Revocation Tokens) The patents on these techniques begin to expire in May 2016. Come back then. They have not been available on RAND basis let alone RANDZ. I'm not too interested in them however. S/Key does provide a rapid means of updating status. Torben Pederssen proposed it as the phone tick modus, Micali and Kocher proposed schemes that add in Merkle tree mechanisms. Fast ECC signatures make these moot. > (c) (Possibly) helping other working groups to revise and update how > revocation information are provided (e.g., the client authentication case) CRLs probably work just fine for servers validating private label client certs. > (d) (Possibly) introducing privacy consideration when it comes to revocation > checking Well that is the reason to get away from using straight OCSP. It leaks information. But stapled OCSP solves that problem. > At minimal, I would like (a) to happen. This could be achieved in 6 months > (and we might not even need to meet). (b) and (c) are also desirable in > order to provide better support for non-browsers and small devices (AFAIK, > some work might be relevant for DICE). (d) is something that we should, I > think, all be mindful and at least some considerations should be provided. > The scope of the work, however, will be limited to revocation. I have a different set of proposals: 1) Stapled OCSP with MUST-STAPLE OID 2) Short lived Certificates 2a) With the same key 2b) With different keys 3) CRLs with HBS compression. Right now we are in the middle of deployment of (1) and doing 2a is not too hard. But 2b is a LOT better since rotating the keys every 24 hours makes all sorts of attacks a lot harder. Making 2b work requires quite a bit of prep though. We would have to completely automate the cert issue process. And we would have to make it work with pinning etc.. 3 is new but we can probably get to convergence on a spec faster than 2b because we haven't tried that problem 4 times already. Much less room for bikeshedding. I see 1/2a as stop gap measures and 2b + 3 as the long term approach. Rather than talk about 'the' revocation problem, I think we should identify 2 separate revocation problems Coarse grain: Narrow the vulnerability window from 1-3 years to 48 hours. Fine grain: Narrow the vulnerability window to 60 mins. Short lived certs (2b) are the best solution to coarse grain revocation but it is really hard to get them working well for a window of less than 48 hours. We would have to define a trusted time protocol for a start and establish a distribution infrastructure for it. HBS(3) can be used for both coarse grain as well as 2b at current certificate issue rates. But it is a compression technique and it only reduces the size of the problem by several orders of magnitude. If cert use grows by an order of magnitude we are back in trouble. That said, combining HBS with short lived certs gives us a path to achieving fine grain revocation. And that is critical in the longer term. The criminals do most of their fraud in the first 24 hours after putting a server live. Short lived certs have the enormous advantage that the vast majority of revocations are for administration reasons, at the request of the cert subject. Revocations for end-entity breach are much rarer. But the problem is that we don't have an accurate means of distinguishing between the cases. Our customers don't want to tell us when they have done something doofus like selling the hard drives with private keys for a live cert. Short lived certs have the nice property that many doofus behaviors time out automatically even if the customer does not catch them. Since it takes more than 24 hours to sell old hard drives on EBay, the keys corresponding to short lived certs will have expired by the time the drives ship. So to sumarize, here is my roadmap Now: OCSP Stapling with MUST STAPLE 12 months: CAs begin issuing HBS compressed CRLs in a form that permits browsers to use them as a basis for constructing 'BigCRL' type solutions 24 months: Begin issue of 2a short lived certs 36 months: Begin issue of 2b short lived certs 5 years: Begin deprecating long lived certs 10 years: Begin phase out of long lived certs 20 years: Stop issue of long lived certs Short lived certs with new keys per cert are definitely the way to go long term. But it will take a long time to eliminate long lived certs - if that is possible at all. That is fine though, provided we can make sure that the majority of the growth in certs is of short lived certs, we will be fine. I think that is going to happen naturally since short lived certs are a much better fit for the cloud than long lived ones. If I use a server for 3 hours, I don't want to rely on the hosting provider scrubbing the memory before the next customer gets hold of it to protect my private keys. I want to limit the scope for service provider defection as well. The barrier to deployment on 2b is writing a good spec for provisioning certs. I have a rough sketch of a JSON prototype that basically just wraps a CSR.
- [therightkey] Proposal for working on PKIX revoca… Dr. Massimiliano Pala
- Re: [therightkey] [pkix] Proposal for working on … Stephen Farrell
- Re: [therightkey] [pkix] Proposal for working on … Massimiliano Pala
- Re: [therightkey] [pkix] Client-side OCSP staplin… Massimiliano Pala
- Re: [therightkey] [pkix] Proposal for working on … Paul Hoffman
- Re: [therightkey] [pkix] Proposal for working on … Phillip Hallam-Baker
- Re: [therightkey] [pkix] Proposal for working on … Trevor Freeman
- Re: [therightkey] [pkix] Proposal for working on … Phillip Hallam-Baker
- Re: [therightkey] Proposal for working on PKIX re… Ben Laurie
- Re: [therightkey] Proposal for working on PKIX re… Nico Williams
- Re: [therightkey] Proposal for working on PKIX re… Jeremy.Rowley
- Re: [therightkey] [pkix] Proposal for working on … Trevor Freeman
- Re: [therightkey] [pkix] Proposal for working on … Phillip Hallam-Baker
- Re: [therightkey] [pkix] Proposal for working on … Nico Williams
- Re: [therightkey] [pkix] Proposal for working on … Tony Arcieri
- Re: [therightkey] [pkix] Proposal for working on … Phillip Hallam-Baker
- Re: [therightkey] [pkix] Proposal for working on … Tony Arcieri
- Re: [therightkey] [pkix] Proposal for working on … Rob Stradling
- Re: [therightkey] [pkix] Proposal for working on … Nico Williams