Re: [lamps] Considerations about the need to resume PKIX work

"Dang, Quynh (Fed)" <quynh.dang@nist.gov> Tue, 25 July 2017 18:20 UTC

Return-Path: <quynh.dang@nist.gov>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C88F12ECF0 for <spasm@ietfa.amsl.com>; Tue, 25 Jul 2017 11:20:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 PhQvsuipwdNt for <spasm@ietfa.amsl.com>; Tue, 25 Jul 2017 11:20:33 -0700 (PDT)
Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0093.outbound.protection.outlook.com [23.103.200.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6671F131E88 for <spasm@ietf.org>; Tue, 25 Jul 2017 11:20:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ynsp+HEFE4RTb2ZeDY0qi8KaqkDjupXQ721DNopn9vk=; b=zUyg05F41eMq+iXI0rsM0qOLKQVCFl7CX945ALM7ZGZVUsN2KCLlG/u/CbjQqz1MtBjUupG63vQHLbmHxnnvfiYfudYghJOxgWZZZOXAQK9z+j2cYTgRrrRjiBGEZ8CG1hNgoF8yZdvBBKZXPUftAb1cUNuYnUoPjxCldTVfdsc=
Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Tue, 25 Jul 2017 18:20:30 +0000
Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.1282.020; Tue, 25 Jul 2017 18:20:30 +0000
From: "Dang, Quynh (Fed)" <quynh.dang@nist.gov>
To: Russ Housley <housley@vigilsec.com>, "Dr. Pala" <director@openca.org>
CC: LAMPS <spasm@ietf.org>
Thread-Topic: [lamps] Considerations about the need to resume PKIX work
Thread-Index: AQHTAUyRJqD8Fgk8HkOtHcW6sHgBpqJcmCcAgAhKaLU=
Date: Tue, 25 Jul 2017 18:20:30 +0000
Message-ID: <CY4PR09MB1464D8F73E5F96E76ED62B6BF3B80@CY4PR09MB1464.namprd09.prod.outlook.com>
References: <04e73e42-7c5b-912d-cc79-7959a710927e@openca.org>, <C9C409F5-778F-4BEF-98B7-10D86996F1F8@vigilsec.com>
In-Reply-To: <C9C409F5-778F-4BEF-98B7-10D86996F1F8@vigilsec.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov;
x-originating-ip: [129.6.231.6]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1464; 7:SByP+rhUZtGa7h1RIEfTDy5BQUS5r1wVcXrMMPw/zULnG90MAHeUuzo+DCcZiiqwpR7gG8HgvGxn/RwtdkSJ4dNMFjc1DrLEf+Tbw0RTu+x1CQ2SIkc0S9t67n1MyAVUHCuzSrxTA2nRWN11N+BVyMGSKxyir/LvkTVW4D1iD2t3yLZrC7vHt9EDN1WUKmoSUSDcefrBHkPGCvOZDg+c2sXuD4cxz17Y3tYGABNLKH/sQeoz4kEnr0yf1+LkJV3RBQFq7kBQZlkTHgbv/fw6x5dg9Zvhcg6Ng4bnxmhLhgkbQ7SygBUpU1eY+4XG/R3odFjiMOzfLOn7ktrAArMfApQPzM7xdIQqMaIBBIM+xP+j42zEbvHGqhh5ifGOv4rNA9sk6hZxvFmB30JWR0AtgerEFoT1CQdwRmxhpqxO/VKir0cJ+ZTxPQhNPd/qwnQra8bUxEsQjKMfk5h4QxdjSVMKZUV3WJ49jktl8jPplwK3nzX8wIvJ3NVNW3Z1XumR1geMudSvJgqBc47/DhM4f8tMr+kTTGfqX51DSoP3r9Fl6EvRHNg2mawmYj5qiMMF92jEkhlEWyARx+TEuQwWs6XBuQJ5/xxNvmZASln8vquFWhM9DzO2N96Akg/1s2ju0lp2z9yOvpM/UCI/L/lXpCXSDS/64Qf3Ce4xnTTFb9yX6EQPN1kVcYWGSWuJt8GQKA5859CmMedPrs9d3+mDJZgtTwp/IqVjd1aBo81jMglm76TVsMM43dts7NXxCVTunDdds7DcG7YJpNGayC6/sG4xHmHbLWb7KMNMato+CC0=
x-ms-office365-filtering-correlation-id: 354ed0b4-5a16-4631-57c7-08d4d389d520
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR09MB1464;
x-ms-traffictypediagnostic: CY4PR09MB1464:
x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705);
x-microsoft-antispam-prvs: <CY4PR09MB1464974B7FDBE6D603D7D608F3B80@CY4PR09MB1464.namprd09.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR09MB1464; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR09MB1464;
x-forefront-prvs: 03793408BA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39850400002)(39410400002)(39840400002)(39860400002)(39400400002)(53754006)(199003)(24454002)(377454003)(51444003)(189002)(25786009)(189998001)(81156014)(8936002)(4326008)(8676002)(33656002)(105586002)(6606003)(3280700002)(106356001)(53546010)(101416001)(966005)(3846002)(6116002)(74316002)(19627405001)(14454004)(7736002)(102836003)(81166006)(3660700001)(2906002)(561944003)(478600001)(86362001)(6506006)(77096006)(68736007)(229853002)(50986999)(54356999)(76176999)(5660300001)(66066001)(236005)(97736004)(2950100002)(6436002)(7696004)(2900100001)(99286003)(55016002)(6246003)(38730400002)(53936002)(54896002)(6306002)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1464; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR09MB1464D8F73E5F96E76ED62B6BF3B80CY4PR09MB1464namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2017 18:20:30.4635 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1464
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/koCw7dOXYCPLpY5rmLYPzes4WmE>
Subject: Re: [lamps] Considerations about the need to resume PKIX work
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jul 2017 18:20:37 -0000

+ 1.


Quynh.


________________________________
From: Spasm <spasm-bounces@ietf.org> on behalf of Russ Housley <housley@vigilsec.com>
Sent: Thursday, July 20, 2017 7:43 AM
To: Dr. Pala
Cc: LAMPS
Subject: Re: [lamps] Considerations about the need to resume PKIX work

Max:

If you can turn these into separate charter items with a description of the deliverable and milestones, then we can discuss each idea on its own.  Of course, in this group we expect that there be a commitment that it will be implemented.

Russ


On Jul 20, 2017, at 7:37 AM, Dr. Pala <director@openca.org<mailto:director@openca.org>> wrote:


Hi all,

I would like to draw the Sec Area attention on an issue that I think is becoming more relevant every day.

It seems quite clear that today there is a lot of work around authentication and encryption that make use of PKIX certificates. However, there is no place in IETF, today, where problems related to PKIX can be effectively tackled. In the following paragraphs I try to summarize the issue and the proposed work and a call for discussion around the feasibility of resuming the work in two particular areas: revocation and discoverability.

The Problem

What I noticed in recent proposals in many working groups (when it comes to certificate management) is that more and more people turn towards the use of short-lived certificates to avoid checking revocation information. Sometimes this choice is motivated by real technical considerations, but in many cases the choice is "forced" because nobody is currently working on fixing the two main issues related to trust infrastructures: efficient revocation and discoverability of services.

The Revocation Situation

Most of the times, when interacting with PKIs, we are still stuck with CRLs, OCSP if we are lucky (including stapling - available in TLS connections if really really lucky), and in most cases even these mechanisms are criticized widely by people as being inadequate today. This resulted in applications to use proprietary methods for checking revocation (e.g., CRLSet) or to skip checking all together (or mandate for short-lived certificates only as in the case, for example, of STIR).

Many people today ignore the fact that, when coupled with small devices, the generation of new keys require (a) a lot of resources, and (b) a good source of randomness. Requiring apps / devices to generate new keys might seem a good idea at first, but is this better than checking revocation ? What about the complexity of key management ?

Examples of possible work to address the issues are OCSP over DNS and some more efficient ways to verify the validity of a whole chain of certificates efficiently.

The Discoverability Situation

As far as I know, there are no standardized mechanisms that would provide discoverability of services that would help users and applications to discover Public Key Services providers and associated services in a dynamic fashion. When I brought it up during the BoFs of possible working groups where the issue could be discussed.. well, the proposal was redirected to /dev/null (e.g., ACME, SPASM, and LAMPS).

Isn't that curious that still today nobody is working on some sort of infrastructure that would facilitate interacting with PKIs ? After all, PKIs are the core Trust mechanism that enables reliable authentication and encryption over the Internet today. Such infrastructure could really improve the security of the Internet and make PKIs more usable from an application (and users) standpoint of view.

Examples of possible work to address the issue are a PKI Resource Query Protocol (PRQP) and/or the use of P2P systems as distribution mechanisms for Public Key related operations (e.g., EST, BRSKI, or ACME over P2P - 0-configuration support for PK).

Deployment Trends in the Real World

Today I am witnessing the deployment of arguably not-well-designed PKIs (or, in other terms, what I call Weak PKIs) that do not provide support for revocation and that are expected to use CAs and EE certificates with validity periods of 30, 35, or 50 years (yes, also EE - especially for devices). Besides the fact that it is a common assumption that the algorithms (e.g., P-256) used in these environments (e.g. IoT) are NOT going to pass the test of time, ignoring the revocation could really affect the privacy of millions of people - and we are currently not doing anything at the IETF to prevent this issue.

There is the need for simple revocation services, but arguably we do not have what's needed today (requires improvements).

IETF Specific Situation and Issues

Why are we so unprepared to face these issues ? I would say (still personal point of view - based on almost 20 yrs of participation in PKI discussions) that these might be some of the main reasons:

  *   There are NO venues where to discuss possible solutions to existing problems. The PKIX working group has been closed down (very arbitrarily, I might say, since there is still a lot of work needed to be done around PKIX as highlighted above)

  *   The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very narrow scoped Charters and only few items (mostly quite marginal issues, IMO) are actually accepted as working items (w/ reference to SPASM and LAMPS in particular). Solving revocation and discoverability issues should be the 1st item and the most important on the list (at least revocation) but they are not - actually when that was proposed to be included as part of the charter(s), the requests were not even acknowledged or rejected with no real technical reasons.

  *   The constant nonsense of people saying that PKIs do not work as an excuse not to improve them while they (PKIs) are the reason we can deploy secure protocols and provide privacy. It is evident that PKIs are here to stay, this is a fact. Their usage has increased exponentially in the past years and they have, so far, passed the test of time. IoT is one use-case. ANIMA is another. ACME is another. Just to cite few of them.

Moreover, things are happening in environments outside IETF (WIFI 2.0 Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on these problems is really scary to me. The world moves forward, fast, and the IETF is standing still on this topic. I really do not understand why.

Final Considerations

In this message I try to summarize the reasons why I think there is the need to provide a venue where these problems are discussed and the need for key people to not actively block the possibility for people that are willing to work on this to have a venue where the work can be carried out.

I think that this work is of the utter importance and I would like to understand what the position of the whole security area is around these points and the proposed work.

I hope that the discussion around this message can spark some interest and that work in the PKIX area can finally resume at the IETF - which was, in the past, thought of as the lighthouse where these issues could be addressed.

A small request, please, try to read this e-mail carefully and consider the implications of NOT taking on these tasks when replying and/or discussing the topic. Also, since I know this (PKIX) is a minefield for "political" reasons (which should not be a drive here), please keep the discussion on the positive / constructive side (thanks).

If you feel like a private response is better than on the mailing list, please just reply privately.

Looking forward to hear your opinions on this hoping that this e-mail can be the beginning of the end of PKIX still-standing issues :D

Cheers,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
<efhklhncoknghhph.png>
_______________________________________________
Spasm mailing list
Spasm@ietf.org<mailto:Spasm@ietf.org>
https://www.ietf.org/mailman/listinfo/spasm