Re: [irtf-discuss] Usable formal methods side meeting at IETF 115

Sampo Syreeni <decoy@iki.fi> Mon, 07 November 2022 21:36 UTC

Return-Path: <decoy@iki.fi>
X-Original-To: irtf-discuss@ietfa.amsl.com
Delivered-To: irtf-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF15C1526F9; Mon, 7 Nov 2022 13:36:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.129
X-Spam-Level:
X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAGIthMjdlnp; Mon, 7 Nov 2022 13:36:01 -0800 (PST)
Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C719BC14F733; Mon, 7 Nov 2022 13:35:59 -0800 (PST)
Received: from kapsi.fi ([2001:67c:1be8::11] helo=lakka.kapsi.fi) by mail.kapsi.fi with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <decoy@iki.fi>) id 1os9mb-00CwHU-RL; Mon, 07 Nov 2022 23:35:55 +0200
Received: from decoy (helo=localhost) by lakka.kapsi.fi with local-esmtp (Exim 4.94.2) (envelope-from <decoy@iki.fi>) id 1os9mb-00CCyb-IN; Mon, 07 Nov 2022 23:35:53 +0200
Date: Mon, 07 Nov 2022 23:35:53 +0200
From: Sampo Syreeni <decoy@iki.fi>
To: Buday Gergely <buday.gergely.istvan=40uni-mate.hu@dmarc.ietf.org>
cc: Colin Perkins <csp@csperkins.org>, irtf-discuss@irtf.org
In-Reply-To: <ff7d4c86-0b30-66ee-4e3e-32a81d0a6df1@uni-mate.hu>
Message-ID: <8ddd2a20-4e43-108c-e789-3d469158bc8b@lakka.kapsi.fi>
References: <C91D3863-37D3-4E09-B1F9-588C316240CD@csperkins.org> <281e560d-0b89-53a5-de75-bfe68004917c@uni-mate.hu> <ff7d4c86-0b30-66ee-4e3e-32a81d0a6df1@uni-mate.hu>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
X-Rspam-Score: -3.1 (---)
X-Rspam-Report: Action: no action Symbol: ARC_NA(0.00) Symbol: R_SPF_NEUTRAL(0.00) Symbol: FROM_HAS_DN(0.00) Symbol: TO_DN_SOME(0.00) Symbol: RCPT_COUNT_THREE(0.00) Symbol: MIME_GOOD(-0.10) Symbol: TO_MATCH_ENVRCPT_ALL(0.00) Symbol: DMARC_NA(0.00) Symbol: RCVD_TLS_LAST(0.00) Symbol: NEURAL_HAM(-0.00) Symbol: FROM_EQ_ENVFROM(0.00) Symbol: R_DKIM_NA(0.00) Symbol: MIME_TRACE(0.00) Symbol: ASN(0.00) Symbol: RCVD_COUNT_TWO(0.00) Symbol: BAYES_HAM(-3.00) Message-ID: 8ddd2a20-4e43-108c-e789-3d469158bc8b@lakka.kapsi.fi
X-SA-Exim-Connect-IP: 2001:67c:1be8::11
X-SA-Exim-Mail-From: decoy@iki.fi
X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/irtf-discuss/gTFjML3L46cX62fn70DMVCGQv3o>
Subject: Re: [irtf-discuss] Usable formal methods side meeting at IETF 115
X-BeenThere: irtf-discuss@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IRTF general and new-work discussion list <irtf-discuss.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/irtf-discuss>, <mailto:irtf-discuss-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/irtf-discuss/>
List-Post: <mailto:irtf-discuss@irtf.org>
List-Help: <mailto:irtf-discuss-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/irtf-discuss>, <mailto:irtf-discuss-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Nov 2022 21:36:05 -0000

On 2022-11-06, Buday Gergely wrote:

> May I get examples of these overly complex protocols and network 
> environments, and the formalisms that that cannot handle these 
> complexities?

So let's try and find a counter-example. Suppose an early PGP style Web 
of Trust, where every participant can vouch for another participant's 
key. But also at any time can withdraw and recertify their voucher. 
Crucially, if there are two or more people vouching for some signature, 
even by way of rumour, they add up to more reliance on a key.

How precisely do you generalize or verify such a protocol when the 
number of verifying nodes goes to infinity? Especially if you model the 
process of growing the WoT as not random, but adversarial? How precisely 
would you defend your proof software against me making it 
computationally expensive, at each step, to grow my adversarial web of 
trust?

Because I think, in this highly realistic problem, I could build up a 
WoT whose recognizers would bump upto at least the travelling salesman 
problem. Maybe the graph isomorphism one at that. I don't yet know how 
to make the problem downright uncomputable/indecidable, but even that 
might be on the table.

I believe all in here is about finding a properly limited logical 
framework, with some mathematical power. If you go too shallow, you're 
not going to get your problem described. But if you go deep, then your 
machinery is not going to work out either. You'll bump into no-go 
proofs.
-- 
Sampo Syreeni, aka decoy - decoy@iki.fi, http://decoy.iki.fi/front
+358-40-3751464, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2