Subject: [saag] Report on Side Meeting about Short Term Automatically Renewed (STAR) Certificates

From: Yoav Nir <[email-masked]>
Date: Fri, 17 Nov 2017 10:57:23 +0800

Hello all

Last night (Thursday) we had a side meeting about the goals of draft-nir-saag-star.  21 people attended the meeting and it lasted a little over one hour.

I got a lot of useful comments, some of which I will list here in no particular order:

The unique thing about STAR certificates is not that they are short term, but that the Relying Parties do not check revocation of the End Entity certificates. The document should be refactored to make this the subject, with short-termness presented as mitigation for the lack of revocation checking (Stefan Santesson).
“Short” and “long” are relative and any cut-off point would be arbitrary. The lifetime of a STAR certificate should be defined by the requirements for revocation, not by some arbitrary limit defined in an RFC.
The draft should add privacy and latency concerns (both are compromised by revocation checking, so a plus to STAR) to the considerations. (DKG)
It should be noted (in the draft) that when the PKI is a hierarchy the RP still needs to check revocation for the sub-CAs. This negates much of the simplicity advantage.
We should consider what use cases are appropriate for STAR. In the web (as measured by Google and others) clock skews are rampant, and 5-7 day skew have to be assumed. Additionally, the CAs on the web typically use one or more layers of sub-CAs.  Closed environments such as datacenters, corporate networks and managed systems have better control of clocks and can often forego hierarchy.
Examples of “managed systems” that were mentioned:
A bunch of NSFs controlled by a single Security Controller (as we’re doing in I2NSF, but vendors have been doing with proprietary protocols for years)
A bunch of IPsec endpoints (either tunneling gateways or hosts) managed by an NSF (we’re doing that in I2NSF as well)
Vehicle-to-vehicle networks where certificates are issued for a month, 20 times a month (Bob Moskowitz)
Storage Area Networks where data clients connect to data servers and require at least authentication and often encryption, which they get using TLS or IKE/IPsec.
STAR certificates seem to be equivalent in terms of security how long it takes to revoke a certificate to PKI certificates with OCSP Must-Staple. The draft should call out that the lifetime of a certificate should be similar to the “lifetime” (time from thisUpdate to nextUpdate) of the OCSP responses.
There was some discussion about whether STAR certificates should be specially marked, perhaps by an certificate extension, as such. The reasoning is that at some point having none or CRL DP or OCSP URI may be treated as invalid, so STAR status may need to be called out explicitly.  Current CABF guidance is that lack of revocation is fine for certificates whose validity period is shorter than X (TBD what X is) so at least for now and for the web such an extension is not needed. If ever such a certificate extension is needed, it can be done in a short standards-track document. The intention is for this document to be informational

Another thing that was discussed is where this work should go.  It obviously requires a lot of feedback, so it doesn’t seem to be a good fit for either AD-sponsored or an independent submission. Neither of these streams tend to get a good review. The authors should discuss with the security ADs and SecDispatch which existing or new WG is the right home for this work.

Thank you to everyone who took the time to attend.

Yoav

---

From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]>
Date: Fri, 17 Nov 2017 23:48:54 +0000

Hi Yoav,

Thanks for organising the meeting and for this report.

Two quick notes/comments:

1.       For data backing the 5-7 days minimum short-termness in the wild, see https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/46359.pdf<https://static.googleusercontent.com/media/research.google.com/en/pubs/archive/46359.pdf> - specifically, the CDF in Figure 4;

2.       WRT where to host this work: maybe a very narrowly scoped WG could be the correct format for delivering

a.       the Informational document about the operational and security considerations regarding the use of STAR and

b.       a tiny PS for the certificate extension

Cheers, t

On 17/11/2017, 02:57, "saag on behalf of Yoav Nir" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hello all

·         The unique thing about STAR certificates is not that they are short term, but that the Relying Parties do not check revocation of the End Entity certificates. The document should be refactored to make this the subject, with short-termness presented as mitigation for the lack of revocation checking (Stefan Santesson).
·         “Short” and “long” are relative and any cut-off point would be arbitrary. The lifetime of a STAR certificate should be defined by the requirements for revocation, not by some arbitrary limit defined in an RFC.
·         The draft should add privacy and latency concerns (both are compromised by revocation checking, so a plus to STAR) to the considerations. (DKG)
·         It should be noted (in the draft) that when the PKI is a hierarchy the RP still needs to check revocation for the sub-CAs. This negates much of the simplicity advantage.
·         We should consider what use cases are appropriate for STAR. In the web (as measured by Google and others) clock skews are rampant, and 5-7 day skew have to be assumed. Additionally, the CAs on the web typically use one or more layers of sub-CAs.  Closed environments such as datacenters, corporate networks and managed systems have better control of clocks and can often forego hierarchy.
o    Examples of “managed systems” that were mentioned:
§  A bunch of NSFs controlled by a single Security Controller (as we’re doing in I2NSF, but vendors have been doing with proprietary protocols for years)
§  A bunch of IPsec endpoints (either tunneling gateways or hosts) managed by an NSF (we’re doing that in I2NSF as well)
§  Vehicle-to-vehicle networks where certificates are issued for a month, 20 times a month (Bob Moskowitz)
§  Storage Area Networks where data clients connect to data servers and require at least authentication and often encryption, which they get using TLS or IKE/IPsec.
·         STAR certificates seem to be equivalent in terms of security how long it takes to revoke a certificate to PKI certificates with OCSP Must-Staple. The draft should call out that the lifetime of a certificate should be similar to the “lifetime” (time from thisUpdate to nextUpdate) of the OCSP responses.
·         There was some discussion about whether STAR certificates should be specially marked, perhaps by an certificate extension, as such. The reasoning is that at some point having none or CRL DP or OCSP URI may be treated as invalid, so STAR status may need to be called out explicitly.  Current CABF guidance is that lack of revocation is fine for certificates whose validity period is shorter than X (TBD what X is) so at least for now and for the web such an extension is not needed. If ever such a certificate extension is needed, it can be done in a short standards-track document. The intention is for this document to be informational

Yoav

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sat, 18 Nov 2017 00:48:30 +0000

Hi,

Looking at the diversity of use cases, and the additional implications that where discussed during the meeting, I support the idea of a very focused WG for this task.

Be goode,
--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]<mailto:[email-masked]>
Tel:        +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------

On 18/11/17 7:50, "saag en nombre de Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]<mailto:[email-masked]> en nombre de [email-masked]<mailto:[email-masked]>> wrote:

Hi Yoav,

Cheers, t

Hello all

Yoav

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição