Re: [Anima] use of CRLs in I-D Action: draft-ietf-anima-autonomic-control-plane-26.txt

[Toerless Eckert <[e-mail]>]

On Wed, Jul 01, 2020 at 08:30:36PM -0400, Michael Richardson wrote:
> 
> Toerless Eckert <[e-mail]> wrote:
>     > The need to diligently document support for CRL/OCSP was done on
>     > behalf of securiy reviews. It is not meant to be a recommendation.
>     > There is mentioning of short-lived certificates in a few places in the
>     > doc.
> 
> I didn't see an RFC8739 reference.  Oh. It's I-D.ietf-acme-star.
> Your section 6.1.5.4 suggests CRLs are unnecessary when the lifetime is on
> the order of hours,  while RFC8739 is less specific about what is short.

2.3 days is one number i found in the RFC.

IMHO RFC8739 is not a relevant comparison for ACP (and i am not only
saying this because otherName killed our ability to use ACME CA with
RFC822 names ;-):

Unless i am missing something, ACP/EST renewal of certs is already the
same "lightweight" renewal that RFC8739 introduces for ACME.

In addition for ANI nodes, we always have re-enrollment via BRSKI/MASA.

Aka: ultimately, the question is whether/how we should deal with
expired certs under incomplete reachability. Max already said that
it should be perfectly fine for EST to accept expired certs as
a valid credential for renewal, that was just never top of mind when
EST was developed, and it certainly would cause hesitation at first
by IETF security review should that be added. 

I for once had to regularily re-activate enterprise WFH VPN clients
that where switched off  for months, then users sent me email, and
i had to go to the VPN server and configure "ignore lifetime for this cert",
so the VPN client would renew its cert.

> I think that a certificate lifetime on the order of a week would probably be
> workable.

I think that if you want to get rid of CRL/OCSP then you need to
get down to reaction time at the order of revocation, which i think
can be as little as 30 minutes. I think its not a problem to do that,
its just far off the beaten track people feel offended to think about
it. There are a lot of network operations aliveness operations at
a 30 seconds interval for every node (aliveness ping). Doing a simple
cert re-signing once every 30 minutes isn't worse IMHO.

> But, I think think we should get implementation experience.

Sure, but there are a lot long-term issues that can happen, sometimes
folks take yeas in deployments to figure out probems with cert lifetime
management, hence the theoretical discussion is useful here too.

>     >> I think that CRLs are not useful, and we should not use them.
> 
>     > I think we agree.
> 
> Good.
> 
>     >> 6.1.3 is clear that OCSP/CRLs may not be available when connecting!
>     >>
>     >> I think that use of STAR (https://datatracker.ietf.org/doc/rfc8739/ )
>     >> Short-Term, Automatically Renewed is the best recommendation!
> 
>     > In general yes, but the STAR use cases typically do not take into
>     > account  connectivity problems that are longer than the lifetime of
>     > a cert, whereas for the ACP this might be a problem.
> 
> yes, but the solution is to find a Join Proxy, reach out to the Registrar and
> renew the certificate using the LDevID one has.
> STAR even went into some detail about how one could renew expired
> certificates, I think. (I recall a discussion, but I'd have to check the
> document again)

Exactly, but that i think was also why the general purpose STAR document
didn't progress in LAMPS. But i forgot all the generic issues there,
i think to remember they are not an issue for ANI/ACP though, but
obviously that would have to be probed by going to LAMPS with a more
constrained EST renewal with expired certs discussion.

>     >> If we have to do OCSP (via https://datatracker.ietf.org/doc/rfc4806/ )
>     >> then we nodes can download their staple and provide it when connecting.
>     >> New nodes can get this using the Join Proxy.
>     >>
>     >> Perhaps this needs to be in a new document at this point.
> 
>     > Yepp.  I think to remember that MaxP was thinking of suggesting to
>     > talk about dealing with expired certs for our cases in i think LAMPS too
>     > but longer ago...
> 
> yes, the document wound up in ACME, and I think they did a good job, although
> it is proscriptive for ACME only, while our end-client interface is assumed
> to be EST.

Yepp. The comparison is probably that doing in ACME the revalidation of
ownership of (domain/email) name is as complex as going through BRSKI/MASA,
whereas doing just EST renewal, worst case via join-proxy (if cert is
expired) is exactly what RFC8739 does for ACME.

Cheers
    Toerless

> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 



-- 
---
[e-mail]