Re: [Last-Call] Last Call: <draft-knodel-e2ee-definition-07.txt> (Definition of End-to-end Encryption) to Informational RFC

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 14 October 2022 17:19 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4CBC14F718; Fri, 14 Oct 2022 10:19:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.408
X-Spam-Level:
X-Spam-Status: No, score=-1.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 X9zPr_89fGfa; Fri, 14 Oct 2022 10:18:56 -0700 (PDT)
Received: from mail-oa1-f54.google.com (mail-oa1-f54.google.com [209.85.160.54]) (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 E7C9CC14F736; Fri, 14 Oct 2022 10:18:56 -0700 (PDT)
Received: by mail-oa1-f54.google.com with SMTP id 586e51a60fabf-132fb4fd495so6579633fac.12; Fri, 14 Oct 2022 10:18:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=2Cwz1jxU0NKjFrQWrb9IgOViDsXtWsaAu+h2zb/QH40=; b=8Lt1dD+7o+xB+7BhYQoWzDauXOGpHcyHXmFSAsKRraCl/AXJbZCbotT4OwvwWs0xAI l+OZ/x+xupCvU8sJC/xnOOgc8xEp8BYu1nxjcPno6rkLv3xVabBUhwiVOeDa39DdxZy8 4Ya+zynmwRDEZBlCROeTrv+LF6+QBgwcGF6uSTil3T3ooZjtawZtQoGxxC3hPgNSPMa5 40OTIeqwIOqMY77tQueIsoDE+2/vWUT8dkUyq9dW242x0MGekhuD1USTZsiWljqWmPJP TqwvVs/fV/TiyinF3jNqA78CntR7jFxvm256qmusx1+olbAqlu9iiHFT9JG6aVT//8JS GClQ==
X-Gm-Message-State: ACrzQf1oA7sBbMfGh4rU8ItjkW60kixnRMa62ADy5W0Gozad5mTMc7KZ dO6u6PWhpcm6uzhN+3pxhF79SVRpkyOacZAwkCrRhoWmLtM=
X-Google-Smtp-Source: AMsMyM7kWDnTBFiSY9HExTAA1p/k3KQm5Qz0nbwPpXQs9aK/7kFCGwbq7pbeQzWRYe3rVV0Hf1W8ALVTFNouOp7JqZM=
X-Received: by 2002:a05:6870:6110:b0:137:acb:5e20 with SMTP id s16-20020a056870611000b001370acb5e20mr6785655oae.108.1665767935854; Fri, 14 Oct 2022 10:18:55 -0700 (PDT)
MIME-Version: 1.0
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 14 Oct 2022 13:18:44 -0400
Message-ID: <CAMm+LwiEjtwynAPbd=M5_UjTn2MU8=rfofKRtk_dQ8CiUaj+Sg@mail.gmail.com>
To: last-call@ietf.org, IETF SAAG <saag@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000184e7c05eb01d2cf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/8ug3ioU4HTY4vOFXDEtgfH5SEZA>
Subject: Re: [Last-Call] Last Call: <draft-knodel-e2ee-definition-07.txt> (Definition of End-to-end Encryption) to Informational RFC
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Oct 2022 17:19:01 -0000

Coming into the discussion mid way through and answering various points
raised in emails, etc. in one post rather than trying to fisk.

As far as action items go, I think we should punt and have a scheduled
discussion in London. This is important and we need to get it right.


Some discoveries from spending four years building really end-to-end
systems that may be relevant:

0) Don't consider practicality

I have running code that does things people say is impossible. Leave
aside assumptions of what is possible based on 1990s cryptography or what
can be done with SMTP and/or TLS.

1) We may need to recognize degrees of compliance.

If we view end-to-end as a monolithic set of criteria, nothing built on
legacy protocols will ever meet them. But if we have a checklist, they
might meet 2/10 today and be able to get to 5/10 in the future and that can
be a win.

2) Distinguish Routing Meta-Data from Content Meta-Data.

Lots of responses of the form 'but the meta-data is visible'. Mail delivery
services only need to see some of the meta-data and maybe less of that than
what people assume. The original design for Mesh Messaging had messages
being sent to an account address. Then I realized that the service doesn't
need to ever see the human readable address, all they need is the unique
account identifier formed from the root public signature keys.

3) Web browsers can be upgraded

I am not at all keen on trying to make Web Mail end to end secure because
there is simply too much code and too much else going on in the browser. I
know about process isolation, etc. etc. but my, what an attack surface you
have there. And as STUXNET taught us, airgaps tend to fail because it is
really difficult to insist on the separation. So what hope...

That said, we could certainly outfit Web browsers with the ability to
securely read OpenPGP and S/MIME encrypted Web Mail. The challenge then
being making sure no other site can get hold of the private keys or the
ability to use them.

4) The end might not be the end

My browser (PHB) has the ability to perform decryption of documents in the
browser itself. So we can encrypt a set of documents, put them on a Web
site and authorized users can view them as normal, no change to the user
experience unless they try to view a document they are not authorized to
see. And because the scheme supports threshold decryption, authorizations
can be added or removed dynamically without modification of the content.

OK, so great win, right? Well not necessarily because what do we do if
someone writes a malicious Javascript that reads documents from a site in
the user's browser and then breaches them? This is not a completely new
vulnerability, but the proposed use case ups the risk model.

So we also need to consider what happens to the data after it is read.
There is a malicious version of the TOR browser being heavily promoted by
Chinese bots which doesn't have a backdoor perse. The browser itself does
not send anything to anyone. Instead, it keeps a list of the sites
accessed, the content downloaded on disk in a place where the state actor
written malware can find it.

5) Data availability is also a security concern

One of the big mistakes I think we made during the cryptowars was to
dismiss the need for key escrow completely. I have several Terabytes of
extremely valuable (to me) data. I have that data stored at offsite
locations in case of a disaster. But I can only encrypt that data if I am
absolutely, completely sure of being able to recover it.

A government mandated backdoor is certainly not a key escrow system. If my
house burns down, would Team Louis Freeh have helped me recover the data?
Of course not.

So rather than saying "backdoors" ... are often presented as additional
design features under terms like "key escrow". I think we need to say that
a backdoor is NOT a key escrow system, these are two entirely separate
functions and in most cases distinct technologies.

6) What is a third party?

We make a mistake when talking about Alice and Bob because it is not always
about just Alice and Bob. Consider the cases

A) Bob, Alice's lover
B) Bob, Alice's customer support agent
C) Bob, Alice's broker

Bob himself is only the real endpoint for case A. In case B, Alice wants
the conversation to seamlessly transition to another service agent if Bob
falls under a bus. In case C, there is law in most jurisdictions requiring
the conversations be recorded for regulatory purposes.

Point is that Bob's employer isn't really a third party in this
conversation.

Case C is interesting because while there is a requirement to log the
entire conversation, there are also strong confidentiality requirements on
that data afterwards and the need for continued controls.

7) Who controls key accreditation

Given the amount of hostility I have received over the years for supporting
the CA based model of PKI to enable E-Commerce, I am rather surprised at
the readiness with which so many people have accepted models in which the
curator of a walled garden is ultimately responsible for management of keys.

My 'end-to-end' messaging application insists on updating itself every
couple of weeks. It is really not practical for me to use an app other than
the one the service provider uses and so there is absolutely no way for me
to know what is going on in the app. Uploading source code to github means
nothing because I have no way to know if my app matches that code.

So ultimately, I am relying on the operator of the service to shut it down
rather than submit to a demand to slip in a backdoor. And the attack may
come from a state actor who works through bribery and/or extortion rather
than court orders.

Complacency on this issue is putting the staff of these service providers
and their families at serious personal risk. When it comes to espionage,
'do this and your mother will get treatment for her heart condition'
actually means 'if you don't do it, not only will she not get the
operation, she will fall out of a hospital window if she manages to survive
without it'. And that case isn't even the worst of them.