Re: Quic: the elephant in the room

Nico Williams <nico@cryptonector.com> Mon, 12 April 2021 00:26 UTC

Return-Path: <nico@cryptonector.com>
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 269913A2563 for <ietf@ietfa.amsl.com>; Sun, 11 Apr 2021 17:26:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
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 sqYuGI47Bmu7 for <ietf@ietfa.amsl.com>; Sun, 11 Apr 2021 17:26:42 -0700 (PDT)
Received: from cross.elm.relay.mailchannels.net (cross.elm.relay.mailchannels.net [23.83.212.46]) (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 4EC3E3A2561 for <ietf@ietf.org>; Sun, 11 Apr 2021 17:26:42 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 5955C1E1E7D; Mon, 12 Apr 2021 00:26:41 +0000 (UTC)
Received: from pdx1-sub0-mail-a74.g.dreamhost.com (100-105-161-114.trex.outbound.svc.cluster.local [100.105.161.114]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id EB6571E1D35; Mon, 12 Apr 2021 00:26:39 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a74.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.105.161.114 (trex/6.1.1); Mon, 12 Apr 2021 00:26:41 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Juvenile-Soft: 78fea8ec77f1ebd4_1618187201208_124741152
X-MC-Loop-Signature: 1618187201208:2238000095
X-MC-Ingress-Time: 1618187201207
Received: from pdx1-sub0-mail-a74.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a74.g.dreamhost.com (Postfix) with ESMTP id AEC897E790; Sun, 11 Apr 2021 17:26:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=vSVU1Q4VuMlv58dq0RLpfu37Eb0=; b=BeOxg9i8PWD NWKVPMugdEkgU3O6ytPErkJZnNiHa4TNhH9ZzBVw590+NU6Koj5P4YKu3v/CjRin 7R0isbjpZEVqiYdyJhhlnU023AVOL0iieUZuQ/+Ootc2MLyQv832eL4qX7GVei3o PH05xlDDs96+d3NZxrjcz1fJpxtAPsQ8=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a74.g.dreamhost.com (Postfix) with ESMTPSA id CA4368306A; Sun, 11 Apr 2021 17:26:38 -0700 (PDT)
Date: Sun, 11 Apr 2021 19:26:35 -0500
X-DH-BACKEND: pdx1-sub0-mail-a74
From: Nico Williams <nico@cryptonector.com>
To: "Salz, Rich" <rsalz@akamai.com>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
Subject: Re: Quic: the elephant in the room
Message-ID: <20210412002634.GO9612@localhost>
References: <3b25c77d-e721-e86d-6c34-a90039aab0e2@mtcc.com> <CAMm+Lwhi8xwFgZJL7jod2g4urZt_f+dm0tNi+3y1osqOfch2mQ@mail.gmail.com> <3593a01f-73f4-7d03-a85b-dff64a8b070e@mtcc.com> <506A780B-9C0D-4F4A-B045-098F6152F4DB@akamai.com> <20210411195854.GL9612@localhost> <94707E61-D7D2-4494-B88C-E229C8D8F3E4@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <94707E61-D7D2-4494-B88C-E229C8D8F3E4@akamai.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/DOhOEQJKveg5LAh9E3SRfyYC0O0>
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 00:26:47 -0000

On Sun, Apr 11, 2021 at 10:18:39PM +0000, Salz, Rich wrote:
> >  Imagine an e-commerce site connected to
>     > two CDN’s who needs to switch.
> 
> >    Not for DANE though.  If you want long-lived TLSA RRs + the ability to
>     quickly change keys, then use TLSA RRs to "certify" an intermediate PKIX
>     CA.
> 
> 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.