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

["Dr. Pala" <[e-mail]>]

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

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