Re: Quic: the elephant in the room

Michael Thomas <> Mon, 12 April 2021 15:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A8D93A21D4 for <>; Mon, 12 Apr 2021 08:13:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X7VnS2tSnVrj for <>; Mon, 12 Apr 2021 08:13:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9776A3A21CB for <>; Mon, 12 Apr 2021 08:13:45 -0700 (PDT)
Received: by with SMTP id f2-20020a17090a4a82b02900c67bf8dc69so9016619pjh.1 for <>; Mon, 12 Apr 2021 08:13:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=WBus0uYB2MlQ785VQsrMdPHUoMe4DNr3Xw2l//H15vo=; b=G+DULx5z0q/A4Ik6LHNougOkUJ/M8ETWFS3MtoFf1rh7yvAOLIF5DXYvv2wyBYioLT ScSuamwQwb7HBl9+/Gwl2TL2UTmdmwHdggrLmuCf6+Ytk7QD/4rjutpF7kRnJvAhR72V cQCJgBJ6BhatJhlwSwS0+ZAu5HfjBRVP62U0d5WNolibnWIhCTTSdjlG91h+JZar61vy vSDhtlM3D77a59aC0E0an1cao4gPvCPrf2kFKfrU66N5UUCHRSMM3Y6sglx3qAI3VJ4+ 6GHUX6sDmSVlGib0kc9DjlsKND4gcWtz0eRHjmkGtbkR2r6J73XW0svD8FbemN1dkaAX XJLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=WBus0uYB2MlQ785VQsrMdPHUoMe4DNr3Xw2l//H15vo=; b=NVJ3sQ8sVU2N+BebrxId6F2yGNQ173rvZ+CQY5u74P5o7/b2JPt0eaMPCbnMuA7JO0 d5dNLU1Uv7vzjjO1kt9QHvZO/cw/8UtjeG7iLO980Ap4lTaK+Ne/CI8r5eQb5XeJim7L fw/67zqMf4+DneLIv3xmewRJZ+LHi3Pomi21MtJ6cr/LyaUvaP/ZU49xwwJQ6tcjtB1E ohnNf2SypRyUQGGg+glOvFsOjyyFPiJ9n9qx9WYDjwaEQ0IO4aagfQdtJEaP/7mFZQJX hcPleZoNln+plvNhtk0s+gH+ckp82qCDa5AllFmpEu4AApZTDYD/yFcjH05KSq1kblME k52Q==
X-Gm-Message-State: AOAM530jd8kWudVyRM94wWQDb5LSCMGGbkwpsTAIylxPvl5Niq2f1sqC SyY269geiTRR5OYuwfS3njRpfYWWRc21Ig==
X-Google-Smtp-Source: ABdhPJx2mU/yza9ObAAMUzkFekNhdtr1KwCLVy53Ucz/FoN4zmSxUGr52gWSb3KHzHMRhqKBSesPHQ==
X-Received: by 2002:a17:90a:ee95:: with SMTP id i21mr30572817pjz.160.1618240423460; Mon, 12 Apr 2021 08:13:43 -0700 (PDT)
Received: from mike-mac.lan ( []) by with ESMTPSA id a13sm12059300pgm.43.2021. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Apr 2021 08:13:42 -0700 (PDT)
Subject: Re: Quic: the elephant in the room
References: <20210412021224.GP9612@localhost> <> <20210412002634.GO9612@localhost> <> <> <>
From: Michael Thomas <>
Message-ID: <>
Date: Mon, 12 Apr 2021 08:13:41 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Apr 2021 15:13:50 -0000

On 4/12/21 5:57 AM, Salz, Rich wrote:
>>     one may as well delegate the TLSA record management to the CDN:
> Sure, if you're never going to switch CDN's.
> Many big customers switch CDN's and will not delegate because, well, they need to switch.
> There is a whole industry and providers around switching CDN's in real time.  Web-search "Cdn switch" will find them, for example.
>>     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.
> Sure, if there's one CDN.
>>     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?
> If millions of dollars of commerce are happening per minute, then yes.  Or the head of state dies and the official news source is overloaded.
So the whole world needs to revolve around somebody's corner case. But 
this is all rather pointless: short TTL DNS devolves into the 
certificate case's message count. For normal TTL records, it would be 
usually be a 3 way handshake. Also: certificates are not going to be 
deprecated; if they work better keep using them. It's really that simple.