Re: Quic: the elephant in the room

Michael Thomas <> Sat, 10 April 2021 17:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34EC23A152E for <>; Sat, 10 Apr 2021 10:04:38 -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 PYI2eHb1AoGH for <>; Sat, 10 Apr 2021 10:04:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1035]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C385E3A152D for <>; Sat, 10 Apr 2021 10:04:33 -0700 (PDT)
Received: by with SMTP id j6-20020a17090adc86b02900cbfe6f2c96so4784600pjv.1 for <>; Sat, 10 Apr 2021 10:04:33 -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=vtXo2wij02zS3iOVJyiLreuR7Tb+Qc0Pa4ocWduJ8TI=; b=ATFJXSOTQNJwtCqzvlg1Gh3FwRiC77V+Y7ZBk3NWw9YhOf39efN6A2bQ/CZl8fu91M X9uUs3YtxBCs/AUcAEh/ccu7Yxv3MiOSW1ZchcxKRw5wx8hWde+qhiKBA9SRIfwonNRB iKo5cFspvhIJ2Xa75/ejVOaVvdkmzmZclaoo+dRz3z9wKFm+F9SkdP5nYpAjgqAG3wVc 0mKd8LBKT1IzdXFTUqpJqOjKCyMDcMgZteC3uu4AJjJPfETJ7ewgkh02aMLcFHg5oYx3 gBmS+OZwVGCFpF6BXNB8ZDM35mVvCI//G+486csSwIdYFSipg3cZmYB5Jtpv8pUPz+Hm Ufnw==
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=vtXo2wij02zS3iOVJyiLreuR7Tb+Qc0Pa4ocWduJ8TI=; b=YXOJGILgDQLEmBvTknvcDkMZRbMR/mJTB4Va7tWNiWS/bdInPL5637sb1cL4e5EpmJ TR8liffGCRS45rEWSu3B26T0+d8amAaa6gqUgQ327bqPt+MuA+foHqjObATeZDBQcWnM 4kaKY3DKaU1iGwBXznVUAZoM7++p/6ZS6fPmIr/SJNGr/yaPCUEAHKjwvB/9tJqqotDC RPqQD8WvjPqW1EE13LZVS8HTsvSzOyYydXg0yBDYSNg+QQLJscegPjLyV6eoMbH4rjno 3dmVaWnaSD68O5RqqCmUIQHcvMB/kfNxxfUTTaTn9DGWpm9f1qtJvafRuRIH3OG2o+Ce cCHQ==
X-Gm-Message-State: AOAM532fhSHn/o1KqtpDNnHTOCMuF4JTpGem/yvpEqsnn4PBuqXWq2GZ buyhX4GxhszckoftQnrpXIQ/yYhaeTsBtg==
X-Google-Smtp-Source: ABdhPJyAiCTK488pm2kInguONS40x80McZ2b38GQvpfChqgnaGwJtlWm8+ryo2y0Y1WgZClChifVsg==
X-Received: by 2002:a17:90a:94c4:: with SMTP id j4mr7586314pjw.14.1618074272203; Sat, 10 Apr 2021 10:04:32 -0700 (PDT)
Received: from mike-mac.lan ( []) by with ESMTPSA id t5sm5551600pjs.47.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Apr 2021 10:04:31 -0700 (PDT)
Subject: Re: Quic: the elephant in the room
To: Ben Laurie <>
Cc: Phillip Hallam-Baker <>, IETF Discussion Mailing List <>
References: <> <> <> <>
From: Michael Thomas <>
Message-ID: <>
Date: Sat, 10 Apr 2021 10:04:30 -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="------------67902C2C8277F4133ED581E9"
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: Sat, 10 Apr 2021 17:04:38 -0000

On 4/10/21 2:29 AM, Ben Laurie wrote:
> On Sat, 10 Apr 2021 at 00:35, Michael Thomas < 
> <>> wrote:
>     On 4/9/21 4:26 PM, Phillip Hallam-Baker wrote:
>>     It is only a 'three packet handshake' if you ignore the off path
>>     interactions with the DNS service. The timeout on DNS tens to be
>>     rather smaller than that most would be comfortable with for crypto.
>     I don't see why 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.
> When I was designing Certificate Transparency, Chrome ruled out any 
> side channel communications requirement during handshake. Given that 
> DNS is required anyway, perhaps this would be different. However, the 
> other problem is introducing DNS as a trust root - the DNS hierarchy 
> is considerably less secure than CAs were even before CT but now it's 
> really a very poor option in comparison.
> Could be fixed with DNS Transparency, of course.
DNS is the natural trust anchor for the internet. And I don't know what 
"considerably less secure" means. If you mean that DNSSec is broken, 
then you should say that. If you mean that DNSsec deployment is thin, 
that is quite another thing, and that is all about the incentives to 
deploy. I don't consider a plethora of CA's of varying security 
responsibility to be a feature and in fact is a bug.