[perpass] Open Interoperable Service

Phillip Hallam-Baker <ietf@hallambaker.com> Wed, 19 April 2023 15:34 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFCEC1516FF for <perpass@ietfa.amsl.com>; Wed, 19 Apr 2023 08:34:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Level:
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.096, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 M1JfnzsYtcTQ for <perpass@ietfa.amsl.com>; Wed, 19 Apr 2023 08:34:48 -0700 (PDT)
Received: from mail-oo1-f44.google.com (mail-oo1-f44.google.com [209.85.161.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A78BEC15155B for <perpass@ietf.org>; Wed, 19 Apr 2023 08:34:48 -0700 (PDT)
Received: by mail-oo1-f44.google.com with SMTP id 006d021491bc7-541b654ab7eso792548eaf.3 for <perpass@ietf.org>; Wed, 19 Apr 2023 08:34:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681918487; x=1684510487; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=VzCbftkL4qUgHpAnzWrOajXLRB061+mczsYVifo4/+0=; b=UnDPKgWbWcUfat11BddiVWHaTqm5cB9x+IDqcqHj88ohd1Rn+YJRlMoceshxvd1db5 Vpr0hyMqNra7F3Foy/f3+CPnMOG2m4EQjNHjsrkfVgijOv6MWDoAlqc/IhXAU7XSLbS4 PxmkM4u3qeUzb11DSygkoHp9xWctcL4Y8Wwco3HTZp7mTW69X+TWPGnfrRqiwk942WM2 8bNJj6I2MBOZQbYS9C+CzsjkLkd5vN41NL6fhy82SBTqoRTFrEljKvHUv2lvcvOm6TId VQXjEXQY4XOMQteAWTrHilNUYKsjOecNWPMxhvRodjoYBZJOcLcLDMT2GdFHWBmSVCcD 2nQQ==
X-Gm-Message-State: AAQBX9fB9yWJfOd9ZFwMMfJXRT7d/K8UYI61psQd3hAxW9+eZ3v7pmdd ABsbSRDYlvJqvl5HJHA6M+kIOPJnEQicBSxbQ2+BgER0
X-Google-Smtp-Source: AKy350YlJc49q2iYCaSu7MbpRBOHX7i99tI5ppoJ3nsCpynEp5UnEKClSCXt6hr1/PSZFs8tmspaQzXccJe03LkWwDo=
X-Received: by 2002:a05:6870:c834:b0:187:e149:9d0d with SMTP id ee52-20020a056870c83400b00187e1499d0dmr37975oab.6.1681918487405; Wed, 19 Apr 2023 08:34:47 -0700 (PDT)
MIME-Version: 1.0
References: <81e9a0f5-6840-2190-4ebe-2bf655fd2062@cs.tcd.ie>
In-Reply-To: <81e9a0f5-6840-2190-4ebe-2bf655fd2062@cs.tcd.ie>
From: Phillip Hallam-Baker <ietf@hallambaker.com>
Date: Wed, 19 Apr 2023 11:34:36 -0400
Message-ID: <CAMm+LwjmucE+5F6RY_5c8TTeoh1KY5PWMztv-2ZotHnCoKhqVA@mail.gmail.com>
To: perpass <perpass@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fbaa9d05f9b22907"
Archived-At: <https://mailarchive.ietf.org/arch/msg/perpass/cQTduFSTnfymx9gHIUgRlKnQTTE>
Subject: [perpass] Open Interoperable Service
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/perpass/>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Apr 2023 15:34:50 -0000

Would this be anything to do with the UK prohibition of cryptography bill?

If so, having read the bill closely, the entire thrust is putting
responsibilities on the 'service provider'. Which is clearly conceived as
being a large organization that is within UK jurisdiction.

Signal, Wire etc. clearly meet that definition and are vulnerable because
they are a large monolithic service. So the only viable strategy for them
is to refuse service to UK residents.

A service like Signal etc. can provide intercept capabilities in several
ways:

* Backdoor into the application
* Application leaks private key
* Public key directory returns key for MITM attacker
* Refuse service unless the application supports the required backdoor.

The only way to defeat these attacks is for the service to be designed so
that the service cannot defect. We have to make it 'zero trust' with
respect to confidentiality.

But what if there was an open, interoperable service like we have for email?

This means users can pick their own client from any provider that
implements the spec. That closes down a lot of the attack vectors.

It also means that users can be their own service provider. Which
completely negates the assumptions built into the bill.

The downside to this approach is that open standards tend to evolve rather
more slowly than single vendor services. But given that most of the changes
seem to turn out to be making the service worse for the user over time to
extract maximum rents, this is maybe an advantage.


PHB.