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

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

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 <[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
>>
>> Cheers,
>> Max
>>
>> -- 
>> Best Regards,
>> Massimiliano Pala, Ph.D.
>> OpenCA Labs Director
>> <efhklhncoknghhph.png>
>> _______________________________________________
>> Spasm mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/spasm
>
>
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm