Re: snarls in real life

Christian Huitema <huitema@huitema.net> Wed, 21 April 2021 17:08 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4884B3A2FBF for <ietf@ietfa.amsl.com>; Wed, 21 Apr 2021 10:08:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAqpxsXxBXIL for <ietf@ietfa.amsl.com>; Wed, 21 Apr 2021 10:08:40 -0700 (PDT)
Received: from mx36-out20.antispamcloud.com (mx36-out20.antispamcloud.com [209.126.121.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 593613A2FBA for <ietf@ietf.org>; Wed, 21 Apr 2021 10:08:40 -0700 (PDT)
Received: from xse217.mail2web.com ([66.113.196.217] helo=xse.mail2web.com) by mx134.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1lZGL7-000fBo-NS for ietf@ietf.org; Wed, 21 Apr 2021 19:08:39 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4FQRpS5p2vzP52 for <ietf@ietf.org>; Wed, 21 Apr 2021 10:08:32 -0700 (PDT)
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1lZGL2-00067R-Ls for ietf@ietf.org; Wed, 21 Apr 2021 10:08:32 -0700
Received: (qmail 8940 invoked from network); 21 Apr 2021 17:08:32 -0000
Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.58.43.58]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <ietf@ietf.org>; 21 Apr 2021 17:08:31 -0000
To: Michael Thomas <mike@mtcc.com>, ietf@ietf.org
References: <93fedaa0-5ad0-dcc0-ff01-43b8e1c97989@mtcc.com> <19f2b2e1-6365-480a-86f2-111377cac2de@www.fastmail.com> <7c77e401-4703-3921-d15d-6d69b74df488@mtcc.com>
From: Christian Huitema <huitema@huitema.net>
Subject: Re: snarls in real life
Message-ID: <fc2d4767-971f-3f27-bc95-e465ff51f4a7@huitema.net>
Date: Wed, 21 Apr 2021 10:08:30 -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: <7c77e401-4703-3921-d15d-6d69b74df488@mtcc.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 66.113.196.217
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x9j7219Tb9QoiGKb6esGsuKj/EwzSHE5FGYwwjsNRPCBef hpOB5FQ20PZ7X5E8KiTmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7Imca+xnn3Ohf8XY5WZ+f/Kk3UxQ6V51u76v35b1wNe/MvdIN+Yj9 JT+HIE3AciYbXmyy2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NDxdyIeJZUl7T+dBx2dACj61gW8YJw4wOSzntoSLm724n fGsIlenjgMoESM+guMI5DRojSVizNl0ce/s7u0P9b9Tml6eOMCV9kYYwkPx6ZsXvIUzTXkDAiiJi mGhLUFuS2lhaIetXfCg1JdAVrOwKfEsd83us6rHiisysrw7PIpFUoFIvD3sIcP1fhJPM6B/88WFF WZIq5rSl0vT4ddU+sJb1dLGmuWjUDhUrPRIoxbiJ+dym1L8cD17Js0v4cp1MBh6S2payka0jurS4 KrbFkjcKVNeVJ9BXyu9+ceCqThTYg2px1fSoqxQCCHnLMo/m9VKh99btUAanjnMCAH2co+fBoeG+ Hs0afhsY/5zhNYWRVYKU9W9tbmVXJBqdHHDmZEKhyNAv1N35kYWaEdgLurFV5oTvAcwA4rM3FkfW 8/1kE/e7sUnsVpINvARNxpFO
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/FKkopZAxm6KVec3BwZuwEqcOALw>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Apr 2021 17:08:45 -0000

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.

-- Christian Huitema