IETF Logo Mail Archive

Re: [Dance] CRLs/OCSP and DANE at RIPE84

Jim Fenton <fenton@bluepopcorn.net> Tue, 24 May 2022 21:47 UTC

Return-Path: <fenton@bluepopcorn.net>
X-Original-To: dance@ietfa.amsl.com
Delivered-To: dance@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933D4C2B62FD for <dance@ietfa.amsl.com>; Tue, 24 May 2022 14:47:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPjg4uceWkIC for <dance@ietfa.amsl.com>; Tue, 24 May 2022 14:47:16 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D120CC2B6302 for <dance@ietf.org>; Tue, 24 May 2022 14:47:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=U8qC3Gfjyav0ZIhSEBM9IymL8pceg0ksRWMMK602sIs=; b=RHgu8EiZ/YCn1/OrL73+xhBM/N FfH0V0DlzeGiqA5gqhCK0WFCu1wwJcVmxC3Rv+q3Qh2wS5sYaRKwv/ltv4vfrA6u5o+YIoj2dghpB oEdlRzcOaf8wY51xruOh0RuHjrEvESy+ZrqEPFdlR4NA9XRdK2D9/Ossxch54fYeghDg=;
Received: from [64.71.6.2] (helo=[10.100.11.204]) by v2.bluepopcorn.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <fenton@bluepopcorn.net>) id 1ntcMw-0003zo-UN; Tue, 24 May 2022 14:47:11 -0700
From: Jim Fenton <fenton@bluepopcorn.net>
To: Shumon Huque <shuque@gmail.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, dance <dance@ietf.org>
Date: Tue, 24 May 2022 14:47:10 -0700
X-Mailer: MailMate (1.14r5852)
Message-ID: <924BEB7A-1155-4C79-9F62-BA84BB09BEB6@bluepopcorn.net>
In-Reply-To: <CAHPuVdWNe-SFZmRDB5nORs+3fFWgGLVyZKxFSOGx95j4wBpjUA@mail.gmail.com>
References: <887547.1653131902@dooku> <CAHPuVdXED50HMmBzkPCRa6pTqUnD8FA_upyWSMZy9OBt=q1GfA@mail.gmail.com> <19724.1653397933@localhost> <CAHPuVdWNe-SFZmRDB5nORs+3fFWgGLVyZKxFSOGx95j4wBpjUA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dance/P4dlBoz-AHlJsKiT3LMtf5BEPWs>
Subject: Re: [Dance] CRLs/OCSP and DANE at RIPE84
X-BeenThere: dance@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: DANE Authentication for Network Clients Everywhere <dance.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dance>, <mailto:dance-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dance/>
List-Post: <mailto:dance@ietf.org>
List-Help: <mailto:dance-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dance>, <mailto:dance-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 May 2022 21:47:20 -0000

On 24 May 2022, at 13:39, Shumon Huque wrote:

> Michael, if you use DANE, you get DNS based revocation automatically.
> The mechanism is simply to remove or update the TLSA etc record, and the
> previously referenced certificate or key in the record will be invalidated
> at the
> time scale of the TTL.

I wouldn’t call that revocation. I would describe that as (typically) a short validity period. One advantage is that it isn’t necessary to actively renew something at the end of that validity period. But having something that goes away, within say 3 hours after being withdrawn (ietf.org TTL), is a huge improvement.

-Jim

v2.23.0 | Report a Bug | By Email