Dr. Pala
2017-07-20 11:38:51 UTC
[ Cross-Post: LAMS and SAAG ]
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
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
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo