Re: [ietf-smtp] DANE / Fwd: ACTION REQUIRED: Renew these Let's Encrypt certificates by March 4

Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 07 March 2020 09:29 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739363A0E85 for <ietf-smtp@ietfa.amsl.com>; Sat, 7 Mar 2020 01:29:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[FAKE_REPLY_C=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 m3LU9SD78Ad1 for <ietf-smtp@ietfa.amsl.com>; Sat, 7 Mar 2020 01:29:51 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 458823A0E82 for <ietf-smtp@ietf.org>; Sat, 7 Mar 2020 01:29:48 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id D54FF1433B; Sat, 7 Mar 2020 04:29:46 -0500 (EST)
Date: Sat, 7 Mar 2020 04:29:46 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf-smtp <ietf-smtp@ietf.org>
Message-ID: <20200307092946.GN7977@straasha.imrryr.org>
Reply-To: ietf-smtp@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200304003828.7D2FC154D27A@ary.qy> <20200303210604.GA18965@fullerene> <60c385bc383a7cdea8b72aab454e2bb9e672b00c.camel@aegee.org>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/cpbXQOO_HFVEPm-Gz6fK85AdfGI>
Subject: Re: [ietf-smtp] DANE / Fwd: ACTION REQUIRED: Renew these Let's Encrypt certificates by March 4
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Mar 2020 09:29:53 -0000
X-List-Received-Date: Sat, 07 Mar 2020 09:29:53 -0000

On Tue, Mar 03, 2020 at 01:50:14PM +0000, Дилян Палаузов wrote:

> on a very short notice, Let’s Encrypt revokes its certificates with
> the message below.  This effectively means to start and complete
> TLSA/DANE/DNSSEC certificate rollover within 24h.

If, as strongly recommended with Let's Encrypt:

    https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022

you publish "3 1 1" records, rather than "3 0 1" or "3 0 2", and renewal
uses the same key (your key was not compromised).  Then you don't need
to update your TLSA records at all.  You should probably roll over your
keys from time to time when convenient and you can take the time to do
it right, but not for this particular firedrill.

> Is this possible in general, when the DNS TTL on its own is 24h?  Do I
> understand something wrong, stating  that this mass revokation is just
> bad for DANE+SMTP?

Also keep in mind that DANE aside, (unless you also decided to go with
MTA-STS) there's very little other certificate validation going on in
SMTP, and precious little revocation checking, so in a real emergency,
if I had a choice, I'd run with the revoked certs, dual publish
old and new TLSA RRs, and keep DANE working until a TTL or two goes
by and it is safe to switch to the new cert.  I'd also keep TLSA
TTLs at O(1hour) not O(1 day).

> What is the right way to mass revoke certificates involved in DANE?

Keep designating trust in the same keys, and you don't most of the time
care about cert rollovers.  Or just on special occasions when there's
no time to pre-publish TLSA RRs for new keys, reuse the old keys at
those times.

On Tue, Mar 03, 2020 at 04:06:04PM -0500, Phil Pennock wrote:

> > What is the right way to mass revoke certificates involved in DANE?
> 
> Make sure that the CA certificate is sent on the TLS connection too.
> 
> Pin the registrar cert via its public key, not just your own cert.

Here opinions differ.  Trusting a CA that validates domain control as
weakly as Let's Encrypt would not be my choice.  But with half the
world trusting Let's Encrypt's "proofs" of domain control, you can
perhaps be comfortable in knowing that you're not alone...

A properly thought out "3 1 1" key rollover process at least as robust
as "2 1 1" and less dependent on a redundant third party.

    https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html                                                           

Or just "certbot renew --reuse-key"...

-- 
    Viktor.