Re: snarls in real life

Bron Gondwana <brong@fastmailteam.com> Wed, 21 April 2021 22:57 UTC

Return-Path: <brong@fastmailteam.com>
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 544E33A3A2F for <ietf@ietfa.amsl.com>; Wed, 21 Apr 2021 15:57:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.819
X-Spam-Level:
X-Spam-Status: No, score=-2.819 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=FKzxD1hf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=p9wnTlI5
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 4aMZFviMHwoU for <ietf@ietfa.amsl.com>; Wed, 21 Apr 2021 15:57:37 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5813A3A2C for <ietf@ietf.org>; Wed, 21 Apr 2021 15:57:37 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 4044A5C0060 for <ietf@ietf.org>; Wed, 21 Apr 2021 18:57:33 -0400 (EDT)
Received: from imap42 ([10.202.2.92]) by compute2.internal (MEProxy); Wed, 21 Apr 2021 18:57:33 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=kE624Xi tPlcIRfRRpJaPD1Vm+KI+/NzcZWV8TpElc1c=; b=FKzxD1hfmKj+3TidKMKu4ps 5NxmtxX3ldZgOj+fpvm+UE0iqHZDQqfL0gzELEUGD2qJA+emiplsNQV4uEAAL2nh kg2EOAWfTY5g9rwMrTE0XPZOEPZMYyugRA52B4cJIEaiP8mTDt4xIdmFfZtgbs1K W1jdHgWfikmuNoZH8c68DeQYwzRs1bv/ekhy6OCW3WRz4gwA5WT+1/0pfSo7pFUT E7p0vCuhX2FqrwiA9rzpCwneHm9PnTa9JDiC07kYfZ9lFSeaCpyBGdcF7N6GqxQV lv2Lbs6iteZY6gQC0JgYQ9ndcwEEJIr1SIl80s9iw0FnyDA4iOq8dtbGrreHlWA= =
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=kE624X itPlcIRfRRpJaPD1Vm+KI+/NzcZWV8TpElc1c=; b=p9wnTlI5zPKC6yyLCxx9iJ LPP7wpbvjhbEa07sazUIhmx7Rwv+NYJgBsXly6JWK9KNSJlbKINXKkGQpZfWVFFG Jp4S0fGLTob0QTigQ28E4PRz2IpbgDcLoJR5XShu3fT5ZYV9JG2NyWfyaJJfLLJP tuhuoMDgDbu/Q34TuLVWwSM6TX98Tuz/5sFwDBpB4RIVpqRtQ6N8ya8XZsLIp3m2 hPEZV4TX2qUxjpgDAhi9AoUU3CpVPBL+y6pzFRVTdc+cxwjq5Co7wCWZrMboakdO jZaRwQ2TXTmYtjzkXp/CzPnWBDJOVedVozMFs76vSmz1ZdBm+VqrtzoDJjP+NRUg ==
X-ME-Sender: <xms:3K2AYCHVtqAe7CSZ86uNEgek9Xai8oE8tvfeAG-Kr0eCaCib0H1beA> <xme:3K2AYDWBthFM2LBF_3p9iPgPI7N-2Xw_CNXYz8eNBDEnmFCTTYQfq-bO-dGbrFarz EbR0smVNPw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddtledgudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeffkeejueeihf elgedufedtleefuefhtdetledvtdevleeggfetveettddujeefteenucffohhmrghinhep fhgrshhtmhgrihhlrdgslhhoghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh
X-ME-Proxy: <xmx:3K2AYML5Bo190q6fW7TORmzuHhIWAoDNmqOlCOu82yQQThrPUT4cmA> <xmx:3K2AYMEPGBDRnalW95saV8cG_dKw-G73uhg_QN_jqoa3Tp4V1uZSFQ> <xmx:3K2AYIXflZjjrrINNBx0xV2PgZLrMEvTAq0x-bigD7c1-LByT0TMKQ> <xmx:3a2AYAhjBh8C7kRNLY5Z2X4gbASLbJcPuRUlFfFNQYRyD-i1j8DHnA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 863D7310005D; Wed, 21 Apr 2021 18:57:32 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-625-g0392165453-fm-ubox-20210419.003-g03921654
Mime-Version: 1.0
Message-Id: <914f3492-d56b-40ca-b7e0-bbbc65603dfa@dogfood.fastmail.com>
In-Reply-To: <7c77e401-4703-3921-d15d-6d69b74df488@mtcc.com>
References: <93fedaa0-5ad0-dcc0-ff01-43b8e1c97989@mtcc.com> <19f2b2e1-6365-480a-86f2-111377cac2de@www.fastmail.com> <7c77e401-4703-3921-d15d-6d69b74df488@mtcc.com>
Date: Thu, 22 Apr 2021 08:57:12 +1000
From: "Bron Gondwana" <brong@fastmailteam.com>
To: ietf@ietf.org
Subject: Re: snarls in real life
Content-Type: multipart/alternative; boundary=723323f41d2c4d45ad46267b025f124c
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/tBSyTA9gLnA23f1Xv3zTA0jGyoA>
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 22:57:42 -0000


On Thu, Apr 22, 2021, at 02:31, Michael Thomas wrote:
> 

> On 4/20/21 7:46 PM, Bron Gondwana wrote:
>> there's a whole fallacy somewhere which I've had to address a few times already in my own working groups, but which I still commonly see, along the lines of "big companies have masses of resources and hence can easily run experiments or implement arbitrary ideas - and have an obligation to do so when requested/demanded".  They don't, you have to persuade them just as much as anyone else, plus they're slower to move and harder to persuade.
> I wasn't making any such assumption, just pointing out that it was well within the capability of a Google-like company to run an experiment. 


Potato, potato.  You're assuming they have the capability based on their size, not on knowledge of how the teams are structured or what their incentives are, which is my point - why would they want to do this for you?  Why are you entitled to their time and their effort to run the experiment for you?
 * Because Google is big?
 * Because your technical argument is compelling?
 * Some other reason that I missed?

> Instead I got told that signing their zone is apparently "boiling the ocean" which to me is astonishing. If you take that at face value, that is a stunning indictment of DNSSec. 

It sounds like a conversation that's worth having with those who have tried DNSSec and given up, or decided not to try to use it.  The fact that you're astonished by their response is a good clue that maybe there's something interesting here.

Personally, I'm right in there with indictments on DNSSec in general.  I didn't write this, but I stand by it:

https://fastmail.blog/2016/12/20/dnssec-dane/

Rob wrote "DNSSEC is fragile and easy to get wrong in subtle ways."  I say that DNSSEC is operational poison - it's hard to get right, easy to get wrong, and most importantly hard to debug failures when it happens - your users aren't going to be able to report the cause.  It's theoretically good tech, but it clearly isn't getting traction and berating those who choose not to use it doesn't help.

> 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. 


You seem very focused on this "number of packets" idea.  Lower number of packets is nice, but only if the tradeoffs are worth it.  Discarding all the existing progress to restart from scratch with a new design is a pretty high cost and clearly those working on QUIC aren't that keen.  I didn't see anybody jump in that thread and say "hey, I'd also like to discuss this".

And if it makes everything more fragile, that's a downside too.  DNSSEC makes things fragile based on the number of big name sites that screw it up every year.  It also makes it much more expensive - DNSSEC is hard to get right and hard to keep right.

Bron.


--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com