Re: Quic: the elephant in the room

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 12 April 2021 03:38 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0213A2B71 for <ietf@ietfa.amsl.com>; Sun, 11 Apr 2021 20:38:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=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 FlT9JKBKLwjV for <ietf@ietfa.amsl.com>; Sun, 11 Apr 2021 20:38:10 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB943A2B70 for <ietf@ietf.org>; Sun, 11 Apr 2021 20:38:10 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 8B9B7B92E3; Sun, 11 Apr 2021 23:38:09 -0400 (EDT)
Date: Sun, 11 Apr 2021 23:38:09 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: IETF Discussion Mailing List <ietf@ietf.org>
Subject: Re: Quic: the elephant in the room
Message-ID: <YHPAoW8D7K1ew4mQ@straasha.imrryr.org>
Reply-To: ietf@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210412021224.GP9612@localhost> <31A7A397-747D-4099-A3A3-F845137022BD@akamai.com> <20210412002634.GO9612@localhost> <94707E61-D7D2-4494-B88C-E229C8D8F3E4@akamai.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/S5mhMsc7j7LGvJ6S-6Gn9CuAJyE>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Apr 2021 03:38:16 -0000

On Sun, Apr 11, 2021 at 10:18:39PM +0000, Salz, Rich wrote:

> > I don't understand.  Suppose www.ecomm.com, a big e-commerce site
> > (or www.kingdom.com, a government-run broadcasting company, many
> > examples work), uses cdn1 and cdn2 in some specific order and
> > www.ecomm.com is CNAME'd to cdn1. Suppose they want to switch from
> > cdn1 to cdn2 for some reason.
> > 
> > How does www.ecomm.comm switch their DNSSEC records quickly enough?
> > I'm sure I am missing something.
> 
> You publish TLSA RRs for the new one and after the switch you delete the
> ones for the old one.  You can have more than one TLSA RR in a TLSA
> RRset.

I often see CNAMEs used with CDNs:

    www.example.com. IN CNAME www.somecdn.example.

one may as well delegate the TLSA record management to the CDN:

    _443._tcp.www.example.com. IN CNAME _443._tcp.www.somecdn.example.

since the CDN in any case manages the certificate deployment, ...
Therefore, when it is time to switch CDNs:

    www.example.com. IN CNAME www.someothercdn.example.
    _443._tcp.www.example.com. IN CNAME _443._tcp.www.someothercdn.example.

If both providers are known to use the same intermediate CA (say Let's
Encrypt), then the TLSA RRSet can be published on the customer side,
and will survive certificate rollovers so long as the intermediate CA
key is not replaced (as it was recently for Let's Encrypt X3 -> R3).

But any sort of TLSA RR on the customer side, while the cert rollover
are managed by the CDN is too fragile.  The TLSA RRs should properly
be published by the CDN as above.

If indeed sub-minute migration from one CDN to another is required, then
the TTL for the _443._tcp.[...] CNAME would need to be sub-minute.  Is
such a short cutover time really a requirement?

-- 
    Viktor.