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

From: "Dr. Pala" <[email-masked]>
Date: Thu, 20 Jul 2017 13:37:08 +0200

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
OpenCA Logo

---

From: Russ Housley <[email-masked]>
Date: Thu, 20 Jul 2017 07:43:16 -0400

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 <[email-masked]> 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
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: "Dr. Pala" <[email-masked]>
Date: Thu, 20 Jul 2017 13:53:22 +0200

Thanks Russ, will do.

On 7/20/17 1:43 PM, Russ Housley wrote:
> 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 <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi all,
>>
>> 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.
>>
>> 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 
>> 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./
>>
>> 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).
>>
>> 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)./
>>
>> 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.
>>
>> 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)
>>
>>     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.
>>
>> 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.
>>
>> 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./
>>
>> [email-masked] <mailto:[email-masked]>

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 25 Jul 2017 18:20:30 +0000

+ 1.

Quynh.

________________________________
From: Spasm <[email-masked]> on behalf of Russ Housley <[email-masked]>
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:

Russ

On Jul 20, 2017, at 7:37 AM, Dr. Pala <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

The Problem

The Revocation Situation

  *   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.

Final Considerations

Cheers,
Max

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

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 31 Jul 2017 16:27:36 +0000

I am also curious to see what concrete things could be done to improve revocation.  If the answer is “nothing” that’s okay, but if it’s not, I expect OpenSSL will have to write some code :)

---

From: "Dr. Pala" <[email-masked]>
Date: Mon, 31 Jul 2017 10:41:02 -0600

[ Cross Post: Saag, PKIX, and LAMPS ]

I just wanted to thank everybody for entertaining the idea of resuming 
the identified work for PKIX - it seems that we have overall support for 
the work considering the replies across the three MLs, thanks for 
expressing your opinions.

The candidate working group for picking up the work items seems LAMPS 
(thanks Russ for considering the work), so the discussion shall probably 
continue there. I will send the tentative items for the charter and 
milestones to the mailing list and see where this will take us.

Thanks again and looking forward to work on these important topics :D

Cheers,
Max

On 7/20/17 5:43 AM, Russ Housley wrote:
>> [...]

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo