[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"?
- [Secdispatch] Comments on draft-knodel-e2ee-defin… Eric Rescorla
- Re: [Secdispatch] Comments on draft-knodel-e2ee-d… Salz, Rich
- Re: [Secdispatch] Comments on draft-knodel-e2ee-d… Mallory Knodel
- Re: [Secdispatch] Comments on draft-knodel-e2ee-d… Eric Rescorla
- Re: [Secdispatch] Comments on draft-knodel-e2ee-d… Salz, Rich
- Re: [Secdispatch] Comments on draft-knodel-e2ee-d… Alec Muffett
- Re: [Secdispatch] Comments on draft-knodel-e2ee-d… Chelsea Komlo
- Re: [Secdispatch] Comments on draft-knodel-e2ee-d… Mallory Knodel
- Re: [Secdispatch] Comments on draft-knodel-e2ee-d… Hannes Tschofenig
- Re: [Secdispatch] Comments on draft-knodel-e2ee-d… Eliot Lear
- Re: [Secdispatch] Comments on draft-knodel-e2ee-d… Salz, Rich
- Re: [Secdispatch] Comments on draft-knodel-e2ee-d… Alec Muffett