Re: snarls in real life

Christian Huitema <> Wed, 21 April 2021 18:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 354863A316F for <>; Wed, 21 Apr 2021 11:04:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GLxPhk_-VEdt for <>; Wed, 21 Apr 2021 11:04:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D14D83A3153 for <>; Wed, 21 Apr 2021 11:04:02 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1lZHCg-0001Gu-C3 for; Wed, 21 Apr 2021 20:03:59 +0200
Received: from (unknown []) by (Postfix) with ESMTPS id 4FQT2L3RJMzPDV for <>; Wed, 21 Apr 2021 11:03:54 -0700 (PDT)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1lZHCc-0007lX-Be for; Wed, 21 Apr 2021 11:03:54 -0700
Received: (qmail 29598 invoked from network); 21 Apr 2021 18:03:54 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 21 Apr 2021 18:03:53 -0000
To: Michael Thomas <>,
References: <> <> <> <> <>
From: Christian Huitema <>
Subject: Re: snarls in real life
Message-ID: <>
Date: Wed, 21 Apr 2021 11:03:53 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Authentication-Results:; auth=pass smtp.auth=
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x9j7219Tb9QoiGKb6esGsuKj/EwzSHE5FGYwwjsNRPCPAy Xh26eud6b5qG/X5U6lPmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7Imca+xnn3Ohf8XY5WZ+f/Kk3UxQ6V51u76v35b1wNe/MvdLom48E g3of4Y9DlgiJ0nAJ2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NQ/T3Op6Um662jkOH4Bxha61gW8YJw4wOSzntoSLm725W +1X6FFXvLaxMIM0T+PRWDRojSVizNl0ce/s7u0P9b9Tml6eOMCV9kYYwkPx6ZsXvIUzTXkDAiiJi mGhLUFuSOTgtjQWHblEKb/bSn512w7IE8J/5JeSdG7VFq2Z3M1rZcpPgEJKLbDyaC/LdLvvYRiqQ pF6gl/ZdhdDBDOnbjfpVB9v9zY0h8asEYmbGGsJkWjQ4xyeNtxxq2TXT/AfNRUGtV4YytpM83fKA YjDYwhX0XF3qP/dj48psOHFCwviQxKSBCGH0S84CnKX/NUAV3jR5NeVaJQBh0uawl0Cg8nrgSS6D 7FozWS6JHKREtqdEPzY64lXv2dr2sny4a4Sj0cqzvWDlDrFILmNCVZ/264kd2x35zAiBFPp64JaI ysAWfpirH8g1GOR1IFGt5BWm
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: Wed, 21 Apr 2021 18:04:05 -0000

On 4/21/2021 10:49 AM, Michael Thomas wrote:
> On 4/21/21 10:08 AM, Christian Huitema wrote:
>> On 4/21/2021 9:31 AM, Michael Thomas wrote:
>>> Chrome already did the DANE work once upon a time so DNSSec is the 
>>> only missing piece. But the very thought that the number of packets 
>>> exchanged in a transport protocol's setup is *off topic* within 24 
>>> hours and a few messages back and forth speaks miles about how 
>>> broken many working groups are and why nobody wants to participate.
>> My takeaway from these exchanges is a bit different. You are 
>> advocating for using Dane instead of PKI during the authentication 
>> exchange, because this leads to fewer packets. People provided three 
>> different counter arguments. The first argument was that in first 
>> order, performance is measured by the number of round-trips, not the 
>> number of packets, and that using Dane instead of PKI would not 
>> result in big performance gains in practice. The second argument was 
>> that the full authentication exchange is only used in a small 
>> fraction of connections. The other exchanges use session resumption, 
>> and in that case there is no difference between Dane and PKI. The 
>> third argument was that there is no specific work to do in the QUIC 
>> working group on this topic, since QUIC relies on TLS 1.3 for 
>> authentication and TLS 1.3 already supports Dane. Using Dane instead 
>> of PKI is a deployment issue, not a protocol development issue, and 
>> there is no concrete work for the QUIC WG.
> The meta question is whether that is so off topic that it needs to be 
> officially shut down with the working group chairs. The technical 
> merits are what they are. What I was told in no uncertain terms is 
> that I am not allowed to even ask the question. Is that appropriate?

There are a couple of topics that would be clearly appropriate for the 
QUIC working group. A document describing your experience deploying 
QUIC+DANE, for example, would be on topic. If there are issue preventing 
mutually agreeing clients and servers from using QUIC and DANE, that too 
would be very much on topic. On the other hand, your latter posts 
focused on the development of the Chrome browser, its level of support 
for DANE, and Google's willingness to deploy DNSSEC in their domains. 
That very much off topic for theĀ  QUIC WG.

-- Christian Huitema