[Secdispatch] Comments on draft-knodel-e2ee-definition-02

Eric Rescorla <ekr@rtfm.com> Mon, 26 July 2021 23:08 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFA33A0938 for <secdispatch@ietfa.amsl.com>; Mon, 26 Jul 2021 16:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 Ar4HtCJK7oa8 for <secdispatch@ietfa.amsl.com>; Mon, 26 Jul 2021 16:08:31 -0700 (PDT)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE3F63A0935 for <secdispatch@ietf.org>; Mon, 26 Jul 2021 16:08:30 -0700 (PDT)
Received: by mail-ed1-x534.google.com with SMTP id n2so12772293eda.10 for <secdispatch@ietf.org>; Mon, 26 Jul 2021 16:08:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=VQOQu+PWvDMO77NJ9mBoYJeDK2dXSNmQGdBss2sCHXk=; b=SArg/alt35yBs6rSkZLN1ucGnSNfnTWSujvrG0onaKe/bfKB9hjyvafCQkYA53h9ME OBMUDhxQCLf/RgDf6mxxMD35bmhjHpSmyf+B0CUhgGpA0ldrfXoY87lB1P5hJfBC2rnX 9jXZxKi0mkex+7vPC+P/1r1GCgoIY0pXrM9yQfUm4NG8ARlmrsjfaeI2kWQl1RkZ8Nxm rIb1GMAp4u+bNpbXNUqmKz1Qpn6f7ADHPmyVHkJ8zHBj1fEwZRGwXPtInAh1JXsl1dQi GM0pGr5+292lPZio750lFaZZFGJ6k0I1XOA2NpmS3mPx4fHJi+F8m8Vz8gdQT5DuKeB4 Vnpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VQOQu+PWvDMO77NJ9mBoYJeDK2dXSNmQGdBss2sCHXk=; b=MfwMJAniHXOD4sGEa8sJTpKS63D7tA7/hMvYnzustAgao/aGGktgkCApYoHzB0IRmo jD1tpu5P08fIdQOxBJggKkRqSKVeTwFGNDHIzHvKpZEMhM8zQ4oiqh1siUdEopzfXmdX 4UptUaaRTJzAH6argSNY+JxI3h+Lcsx8QnyL83PrdzB34Z3qEmWb2szngJG85lRyc3Ez 5OkMJu2Gggq09GJMOYPy0a9JWKTuORaMc5FHZ1mZrd5Hb4RaMDLsNYypPCOVOGBQ+sxp j3OCkJIPMOyG1//3AmiPby6i9J95dWUxPk4tA6Qc9uwy9jkQOQElr2oKo7u9KzPd0CcN IhNQ==
X-Gm-Message-State: AOAM533lp9BgtLQXye6Vqlc9ZJYMDHeVTAurVFEIPGduC0u9hyLh46l6 tsygGqBB6LbnUHsAumDZFqldjqRAFYERwDJu9Z3BQnUylng1JxR/
X-Google-Smtp-Source: ABdhPJzskAMSaYUfuCcIzf54zy8ywXX1nsdym6Zflj5BMwx/vlyrcauSOm+69/VYTUgldEsaR1zTuB5UwAEwW9Ko+Bo=
X-Received: by 2002:a05:6402:13c3:: with SMTP id a3mr24168273edx.187.1627340907141; Mon, 26 Jul 2021 16:08:27 -0700 (PDT)
MIME-Version: 1.0
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 26 Jul 2021 16:07:50 -0700
Message-ID: <CABcZeBOZwcpvJweCDh_vbd7vL0ccab3S6hKgPHKuoWPUtkBr9g@mail.gmail.com>
To: IETF SecDispatch <secdispatch@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b2eef005c80ed460"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/BwmdjEnXlAjd8u4DWQgeSOKr6rA>
Subject: [Secdispatch] Comments on draft-knodel-e2ee-definition-02
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Jul 2021 23:08:37 -0000

I took a look at this document. While I think it's valuable to have a
definition of E2EE, IMO this document needs a fair bit of work,
including quite a bit of trimming.

Specifically, it seems to me that it's quite hard to talk about E2EE
as an abstract property, because what's E2EE in one context (my TLS
connection to Gmail) is not E2EE in another context (the email that I
am reading that was sent to Gmail). I think what I would do instead
is:

1. Provide a generic definition of what E2EE encryption means
   assuming the endpoints are defined (something like 3.1.)

2. Examine some specific cases of system types, such as
   (1) network connections (e.g., TLS) (2) e-mail and (3) messaging
   such as MLS and describe what we should view as the endpoints
   and the limitations of trying to provide E2E in those
   contexts.

I would also note that there are other ways to be E2E that
are not just "E2E encrypted". For instance, DNSSEC provides
end-to-end authentication/integrity. Another example would
be "E2E" voting systems.


OVERALL
It seems to me that the most difficult problem here is that being
E2EE isn't an absolute property but one that applies with respect
to a certain set of endpoints. As an example, if I use HTTPS to
search with Google, that's arguably E2E encrypted to Google. If
I used HTTPS to read my email, though, we don't think that's E2EE
(absent S/MIME, obviously). So I think you need to treat this more
of a relation and then talk about some common cases and who we
should view as the communications endpoints.


   End-to-end encryption (E2EE) is an application of cryptography in
   communications systems between endpoints.  E2EE systems are unique in
   providing features of confidentiality, integrity and authenticity for
   users.  Improvements to E2EE strive to maximise the system's security
   while balancing usability and availability.  Users of E2EE
   communications expect trustworthy providers of secure implementations
   to respect and protect their right to whisper.

This last sentence seems weirdly hortatorial. I would stick to
the technical points.


DETAILED
S 2.1.
   However despite the nuance for engineers, it is now widely accepted
   that the communication system itself begins and ends with the user
   [RFC8890].  We imagine people (through an application's user
   interface, or user agent) as components in a subsystem's design.  An
   important exception to this in E2EE systems might be the use of
   public key infrastructure where a third party is often used in the
   authentication phase to enhance the larger system's trust model.
   Responsible use of of public key infrastructure is required in such
   cases, such that the E2EE system does not admit third parties under
   the user's identity.

I don't understand this point at all. The third parties aren't
communications endpoints. It's incredibly common to have "e2e" systems
which have third parties such as CAs.


   We cannot equate user agent and user, yet we also cannot fully
   separate them.  As user-agent computing becomes more complex and
   often more proprietary, the user agent becomes less of an "advocate"
   for the best interests of the user.

This seems like it needs to be supported, or perhaps just omitted.


S 2.2.

   identity and end identity.  This creates a tree hierarchy with the
   end user as the root at the top, and all potential end points being
   under their direct control, without third party access.  As an

This seems far more strict than is possible. Consider the case of
a piece of software which allows for remote updates. Does that
mean it is not capable of doing E2EE? Even if we assume BT and
reproducible builds, it still would not meet this definition
because there is third-party access.


S 2.3.
This seems oddly detailed. The question of whether authentication
is symmetric or asymmetric or whether there is a ratched doesn't
define if something is E2EE.

   The adversary successfully subverts an end-to-end encrypted system if
   it can succeed in either of the following: 1) the adversary can
   produce the participant's local state (meaning the adversary has
   learned the contents of participant's messages), or 2) the states of
   conversation participants do not match (meaning that the adversary
   has influenced their communication in some way).  To prevent the
   adversary from trivially winning, we do not allow the adversary to
   compromise the participants' local state.

   We can say that a system is end-to-end secure if the adversary has
   negligible probability of success in either of these two scenarios
   [komlo].

I'm not sure if this is intended to be a formal definition, but
it seems to me that it has a number of edge cases which are
problematic:

1. Consider the case where I persuade you to install a new E2E
   messenger and then send you a message. At this point, I know
   your state, but presumably I have not violated the defn.

2. Consider the case where A sends a message to B but I succeeed
   in blocking that message by (for instance) jamming B's network.
   In this case, the states don't match, but again we wouldn't
   say E2EE was violated.


S 3.1.1.
I of course agree with these features, but I feel like they
need to come with some sort of definition of the endpoints
and who it is you trust. To take some examples:

- I think we agree that TLS between me and Google is E2EE,
  right? But actually, with Google I connect to GFE which
  then decrypts the data.

- I think we would also agree that TLS between me and Google
  is not E2EE if there is a MITM proxy. But what feature
  out of this CIA list is it missing?

- When I connect to a site which is fronted by a CDN,
  is that E2EE? Maybe?


S 3.1.2.
I feel like the / in "optional/desirable" is doing a lot of work
here. There are contexts in which "deniable" is important but
also ones in which "undeniable" is important! More generally,
Availability, FS, and PCS seem desirable whether we are end-to-end
or not.

S 3.2.
I would strike all of this. It's too specific to a particular
set of systems and not really helpful to a definition.

S 4.1.
I agree that "a conversation is confidential" is a good thing
to happen, but it's out of step with the rest of this document
to root it in 7624 or human rights. Let's just stick to
technical points here.


S 4.3.
   message is sent to the recipient" [GEC-EU].  Third party access also
   covers cases without scanning - namely, it should be possible for any
   third-party end point to access the data regardless of reason.

I assume you mean "not"?