Re: Quic: the elephant in the room

Michael Thomas <> Sun, 11 April 2021 18:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 777743A1815 for <>; Sun, 11 Apr 2021 11:14:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=0.001, 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 hWuol80cAubG for <>; Sun, 11 Apr 2021 11:14:04 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E9CD3A1819 for <>; Sun, 11 Apr 2021 11:14:03 -0700 (PDT)
Received: by with SMTP id p12so7604104pgj.10 for <>; Sun, 11 Apr 2021 11:14:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=fluffulence; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=SzeNujdv8+jt4VgYqk7sevP3sTg+h8LEWRdDqByw51Y=; b=QmF/Hv4C2/Z9RN3L++29mvwrl9WfadaAp3oLnXlFUJij9GZP6uMtC69iG4aPQSxpV0 ock4uOiBqIof/kRdHUctINUObwbXHf/45L2kGh8OuRMrUv7omGtK9McEU5iGTGMNx+zn xI7+lfSUGAGa+5+PPDcjac2zfjY1FuCgxNzLphBzUDl5tA6e9d6FqY+pBA2HfGZL2C7N wpLsI0Y41LSVfjQsq0Om4BTnHQNTVICJHIVi9Tgpp/FSlcak+1xJy/VCzYHNuabCCY3w AlB+s19qDLBBvM4VxzIlGUrTlJlvmCih/68MtR3gYfyxthgTIKWtUfFXJ6MvTev+UUCm 2NDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=SzeNujdv8+jt4VgYqk7sevP3sTg+h8LEWRdDqByw51Y=; b=V9+6aK90bbXFoavIFQnId1T+UDJQhj+UnPqEoBdj77/k9UWRP7+Yj48J77jkXMeyXv CsVACeuY8sshrySJWyEGaNeDLoZPJPdooa112hSi4CJ35IrIoxJjWYkeppJE0QC3YwuX QxoUA0rbqEbB0MWwuS23OC7yPH5lHDbVvmfvMzMyK3RIKwg3QRNZWmC1e50usihFbKpz ivUNUi5P2OYzGWzk/W62uggkQDfcUogLqV8bDKK/DgucdIpjArF2Zx85P+DHt1kYM9YS uRI1Ca0JRG4L3E94qQwERA/2VmZsJLRkvTQggircAsw4maq6YNkKXfuXa+sOiOBttMBF +bug==
X-Gm-Message-State: AOAM532ffnxh7mHaAdP5E7nZFwV8DgLatRkGyWCzf8/yEeNdSpTuJxaM zm0UiXic7gBlPWTKzTpLvtM90+Cz3hJbnA==
X-Google-Smtp-Source: ABdhPJy9DBSUtET4bDh7AqSjiyzz5HP3LsgHIBs8hX6GmTRq6qvTCbFyJRbOnBEnT1KjZRaZOXlreQ==
X-Received: by 2002:a63:342:: with SMTP id 63mr22645953pgd.151.1618164841464; Sun, 11 Apr 2021 11:14:01 -0700 (PDT)
Received: from mike-mac.lan ( []) by with ESMTPSA id gm10sm8364827pjb.4.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 11 Apr 2021 11:14:00 -0700 (PDT)
Subject: Re: Quic: the elephant in the room
To: "Salz, Rich" <>, Phillip Hallam-Baker <>
Cc: IETF Discussion Mailing List <>
References: <> <> <> <>
From: Michael Thomas <>
Message-ID: <>
Date: Sun, 11 Apr 2021 11:13:59 -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: multipart/alternative; boundary="------------29EB5E434865A1269E1959A8"
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: Sun, 11 Apr 2021 18:14:08 -0000

On 4/11/21 10:23 AM, Salz, Rich wrote:
>   * I don't see why [DNS timeouts] it can't be long lived, but even
>     normal TTL's would get amortized over a lot of connections. Right
>     now with certs it is a 5 message affair which cannot get better.
>     But that is why one of $BROWSERVENDORS doing an experiment would
>     be helpful.
> There are use-cases where a five-second DNS TTL is important.  And 
> they’re not amortized over multiple connections from **one** user, but 
> rather affect **many** users.  Imagine an e-commerce site connected to 
> two CDN’s who needs to switch.
The worst case is that it devolves into what we already have: 5 messages 
assuming NS records are cached normally.

Another approach using current infrastructure would be for the client to 
cache the certs and hand the server cert the fingerprint(s) in the 
ClientHello and the server sends down the chosen cert's fingerprint 
instead of the cert which could get it back to 3 messages too. That 
would require hacking on TLS though (assuming that somebody hasn't 
already thought of this). That has the upside is that it's the server 
chooses whether it wants to use the cached version or not too.