IETF Logo Mail Archive

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

Toerless Eckert <tte@cs.fau.de> Wed, 01 July 2020 23:41 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570573A11E3 for <anima@ietfa.amsl.com>; Wed, 1 Jul 2020 16:41:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.87
X-Spam-Level:
X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tl4-2nvoTUMp for <anima@ietfa.amsl.com>; Wed, 1 Jul 2020 16:41:06 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AB7C3A11C9 for <anima@ietf.org>; Wed, 1 Jul 2020 16:41:05 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 75A16548068; Thu, 2 Jul 2020 01:41:00 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 6D358440043; Thu, 2 Jul 2020 01:41:00 +0200 (CEST)
Date: Thu, 02 Jul 2020 01:41:00 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: anima@ietf.org
Message-ID: <20200701234100.GC60049@faui48f.informatik.uni-erlangen.de>
References: <159363696301.1694.14970467680230111407@ietfa.amsl.com> <14763.1593644290@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <14763.1593644290@localhost>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/XfKpxstbht99JjSFZ117lICTaco>
Subject: Re: [Anima] use of CRLs in I-D Action: draft-ietf-anima-autonomic-control-plane-26.txt
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2020 23:41:08 -0000

On Wed, Jul 01, 2020 at 06:58:10PM -0400, Michael Richardson wrote:
> 
> the diff for 6.1.5.3.  Certificate Revocation Lists (CRLs)
> fixes some TLAs, but continues to seem to recommend long-lived certificates with CRLs.

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 think that CRLs are not useful, and we should not use them.

I think we agree.

> 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.

With CRL/OCSP, it seems as if we could define the details under
loss of connectivity through these mentioned rules. This seems
like an easily acceptable solution for the proponents of CRL/OCSP
because they couldn't come up with a better solution and its their
technology.

When we are talking about expiry of short lived certs we would be
talking about pootentially authenticating expired certs under
limited network connectivity. Thats quite new and the proponents
of CRL/OCSP would drag along the argument much longer.

> 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...

Cheers
    Toerless


> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 



> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima


-- 
---
tte@cs.fau.de

v2.23.0 | Report a Bug | By Email