Re: Quic: the elephant in the room

Michael Thomas <> Sun, 11 April 2021 19:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8A073A1ADF for <>; Sun, 11 Apr 2021 12:34:43 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 FECbxBpm1Klz for <>; Sun, 11 Apr 2021 12:34:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6A6243A1ADD for <>; Sun, 11 Apr 2021 12:34:39 -0700 (PDT)
Received: by with SMTP id w8so2862818plg.9 for <>; Sun, 11 Apr 2021 12:34:39 -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=HlHIwFfSQYPS3ZIJUUzYJN5l9R0L9E0OqIEyy+PfVJ4=; b=cWckpB4jZFckcm5wrchLiXa33iMMKO7/mw/6VFkuJ44muqw8SKTvtpersEtwTNHOHx P8jP4kY0H8uAffVnwUREiVLgJQqlqGpZ49dgsOzfHGZw+xz45HOpbWOXpejSmxIwA6et FQBkWpen/+SS/zBiShwDSdOgfiVHiKfiYwraKYwjzROCB1o7sTbWEmbyFUZVzFVWPujb Ci9NipmIryA8EAuB8FW/cDE3gfnkan1o89Gd+YhYgYkOuwRfzlUdfNnn4n+ldChi6QTK j1XSDziMZc+UE5MJa8doHPi3laB8+2jUY+mYDbZi2B6l48ffetaQ9n1hQorD2onuwWpq 6v4Q==
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=HlHIwFfSQYPS3ZIJUUzYJN5l9R0L9E0OqIEyy+PfVJ4=; b=W5eYTvl1GgVMxTcEqVe7o9W3RmtofP2XJV6pX+IHV2Eqk52DprrqG6DKcgPynY2IkU cB15D8NlKzdiDDqy5H8oEg2vF1HydzeRKsumsY1r2LpzOxDHZQ+wiBHjern0rD1mIFIt ewSxqB8jvoXqJHIVTWIliEevPhYY0ZN4SIDNsgvb+KyrOND+y/ks5vdUDo2VN7OWSra/ TUZ2+O5fr+5Z8BQOCIohVKP7iIDCP3RdADhvUdfGJT2vO1+vV+QVGwcxJNgdlk3+f4YD qGlt59GzyHGcmGYwGZCHZQK1jMDZjMZmk320mphzOAzM9PSr8prjoO0GvMOZJE+KoXJ8 7fzQ==
X-Gm-Message-State: AOAM533cygumkWGFkwW2/4E5SsVI8mWNTTlEBl7luEDDrBsMAGEj7tNS DfD+rEKUPP9IYPA2QbfgQnD1UpdW00lawQ==
X-Google-Smtp-Source: ABdhPJz3UbOhoVGqEhtH29K3vlSx5W+65iQqNoJOasLNwpMEkYu4vtE2ATIEwRW2CNBGAcbAfSt4nA==
X-Received: by 2002:a17:90a:a781:: with SMTP id f1mr10578643pjq.57.1618169677361; Sun, 11 Apr 2021 12:34:37 -0700 (PDT)
Received: from mike-mac.lan ( []) by with ESMTPSA id j20sm8455328pjn.27.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 11 Apr 2021 12:34:36 -0700 (PDT)
Subject: Re: Quic: the elephant in the room
To: Phillip Hallam-Baker <>
Cc: "Salz, Rich" <>, IETF Discussion Mailing List <>
References: <> <> <> <> <> <>
From: Michael Thomas <>
Message-ID: <>
Date: Sun, 11 Apr 2021 12:34:35 -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="------------DCE71DA353A1FF10F263D3A0"
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 19:34:44 -0000

On 4/11/21 12:11 PM, Phillip Hallam-Baker wrote:
> I made essentially the same argument to people at Google BEFORE the 
> DANE group was ever proposed. The answer they gave me then has not 
> changed.
> DANE was chartered over a decade ago. Individuals in that group made 
> clear that no input was going to be accepted from anyone who was a 
> part of the WebPKI world. The tactics used were intentionally 
> exclusionary. Those of us pointing out the limitations of the proposed 
> approach were never given a fair hearing.
> It is now ten years since DANE was chartered. DANE has failed beyond 
> the very limited application to SMTP which was never really covered. 
> The argument for DANE was weak before LetsEncrypt was launched and it 
> seems highly unlikely future events are going to change that.
> The TLSA model is simply the wrong model. If you want to change 
> the way discovery is done, you need to think about the full discovery 
> chain. And not least because DOH is another factor in this mix.
> DANE and DPRIV should have all been a part of one effort that should 
> have included the introduction of SRV records for HTTP.
> The key weakness in the DNS protocol is that the client-resolver 
> interaction is of an entirely different character to 
> resolver-authoritative and the current client-resolver interaction 
> only supports requests for one record at a time.
> The kick off meeting for DPRIV was quite interesting. There should be 
> standing IESG instructions to prohibit chartering of any WG that is 
> premised on the need to finish something in a year, so it is essential 
> that it be done in exactly the way the proposers have already decided. 
> Even more so when the results from DPRIV could be easily foreseen from 
> the fact it was the same group that had hijacked DNS security policy 
> with DANE.
> I don't claim to always do the right thing but there are some folk who 
> seem to keep doing the same thing with the same outcome and for some 
> reason they get priority over folk who have actually built stuff that 
> was successfully deployed and is in use.
We already have a widely adopted example where we ignored the webpki 
folks too: DKIM. Certs are simply not needed in the vast majority of 
cases. DKIM could be adapted for this too, and doesn't have the downside 
of a new RR type which is always problematic. I assume that the people 
doing DANE were looking at DKIM's success as a template. Quite 
reasonably, IMO.

And I don't know how something that could reduce the message count to 
the original 3 way handshake is somehow the "wrong model". In what way? 
Is DKIM the wrong model too?

My larger point is that a Google-like company could and should run 
experiments to reduce the message count to 3 again to finish off what 
Quic is trying to accomplish. That is achievable, the only question is 
whether it's worth it which experiments would show.