Re: [E2ee] [Secdispatch] Comments on draft-knodel-e2ee-definition-02

Mallory Knodel <mknodel@cdt.org> Tue, 19 October 2021 15:58 UTC

Return-Path: <mknodel@cdt.org>
X-Original-To: e2ee@ietfa.amsl.com
Delivered-To: e2ee@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D073A0949 for <e2ee@ietfa.amsl.com>; Tue, 19 Oct 2021 08:58:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org
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 FMWIE3WAOSki for <e2ee@ietfa.amsl.com>; Tue, 19 Oct 2021 08:58:41 -0700 (PDT)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 2DC893A093A for <e2ee@ietf.org>; Tue, 19 Oct 2021 08:58:41 -0700 (PDT)
Received: by mail-qt1-x835.google.com with SMTP id i1so380619qtr.6 for <e2ee@ietf.org>; Tue, 19 Oct 2021 08:58:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=message-id:date:mime-version:user-agent:content-language:to :references:from:subject:in-reply-to; bh=w+KyGPyxoUEWj2fObKIIIBCK1hTcUHG1k32147r7H7Q=; b=Nan8VLuWp0qGA8UECz83zoHEBjcMrCR5ptbHjrMj/OsZFuZSkMrn6Qv7itBKbIoNZk AKOaN0rOpfoQN6NUA3XZiQv8L5B763ZxRM1bUvFuJcG5egK2h1CroaoMqxE/UahojNOq LMpD+8HVMlnlrraFJMbDD2eNRwyVu4css7Tig=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:references:from:subject:in-reply-to; bh=w+KyGPyxoUEWj2fObKIIIBCK1hTcUHG1k32147r7H7Q=; b=LDbGnmls1DKfrqKGK3PzPov6ocm8gSZxccTvSd2fXxAW7NjlVNz9grcMWoJxkw2XbC pU586OW1k85glRYUWsCZ7m3E1414SBI8u85HKYI25+9As8Tx7NKQOXSGJFoAwLReqRz6 v3ldY0aTvzHxqksydVDa3n1Y8eWrXj3PzMBBsSMLcN9NtoqIR6BEWkpwYFoiA4SD9V+v YaoQthyB1PgvCXxhALCEAtIb7glB5RM7+KQeNfntGdvd0MVFDhstrwPIPBprsR53VAa3 hwYgeotS7wy30Qxv9uAHXmgfrqiRrUUznMhuwfltLpXXI2UkKNlL0aeJxbjIfwjJVZEp IIQA==
X-Gm-Message-State: AOAM530HtWrvzcD2D/nc8WE26LP9pDoYS1PZs46HeMjTTzYcOds4mD9j 6U4Oo+Pfy3Pq9aVimbbbkP+0CQ==
X-Google-Smtp-Source: ABdhPJz9D0nK24pb4bSwCml9KzbykHVVdpZ0ggcylmcjKqyYEwL5vVuFZkvyUOSdzGWdkHuFQOUvcA==
X-Received: by 2002:a05:622a:ce:: with SMTP id p14mr862457qtw.164.1634659119770; Tue, 19 Oct 2021 08:58:39 -0700 (PDT)
Received: from [10.0.3.86] ([50.239.129.122]) by smtp.gmail.com with ESMTPSA id p11sm3661651qtw.60.2021.10.19.08.58.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Oct 2021 08:58:39 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------8xRSNsdP0UmjxhlRJcuCWkdm"
Message-ID: <4bf8dcc0-ac1e-5a01-e5cb-926ca68d9149@cdt.org>
Date: Tue, 19 Oct 2021 11:58:38 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:94.0) Gecko/20100101 Thunderbird/94.0
Content-Language: en-US
To: Eric Rescorla <ekr@rtfm.com>, e2ee@ietf.org
References: <CABcZeBOZwcpvJweCDh_vbd7vL0ccab3S6hKgPHKuoWPUtkBr9g@mail.gmail.com>
From: Mallory Knodel <mknodel@cdt.org>
In-Reply-To: <CABcZeBOZwcpvJweCDh_vbd7vL0ccab3S6hKgPHKuoWPUtkBr9g@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/e2ee/EyjUGFpzK53RkYz3s79iMBDBVtw>
Subject: Re: [E2ee] [Secdispatch] Comments on draft-knodel-e2ee-definition-02
X-BeenThere: e2ee@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of the definition of end-to-end encryption." <e2ee.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/e2ee>, <mailto:e2ee-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/e2ee/>
List-Post: <mailto:e2ee@ietf.org>
List-Help: <mailto:e2ee-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/e2ee>, <mailto:e2ee-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Oct 2021 15:58:46 -0000

Hi Eric,

Thanks for this review.

I've moved discussion from secdispatch to the new list.

Some responses:

On 7/26/21 7:07 PM, Eric Rescorla wrote:
>
> 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:
>
We're aiming for both ends to be people, not services.
> 1. Provide a generic definition of what E2EE encryption means
>    assuming the endpoints are defined (something like 3.1.)
>
By generic do you mean "textbook" or "formal"? It's built up to in 2.3, 
but we've attempted to bring it forward in the abstract.
> 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.
>
2 and 3 seem within scope. If we go the route of identifying system 
types I'd like to add video/synchronous streaming to the list.

> 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.
>
I don't think these are in scope.
>
> 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.
>
We include this last section on users because I think the formal 
definition (section 2) and the functional definition (section 3) need to 
consider what the user expects.

>
> 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.
>
If not "third party" for key servers, what could we say here?
>
>    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.
>
This gets at what I mean but it focuses on browsers: 
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3827421.
>
> 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.
>
Update doesn't sound like "third party access" to messaging 
functionality to me.
>
> 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.
Chelsea-- thoughts?
>
>
> 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 that we are only considering ends as people, which is how it 
should read in the abstract and first section.


> - 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.
>
Agree! I'd like a better title for that section.
> 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.
>
It helps to define the trajectory of where development might go. Solving 
those hard problems might not be featurified yet, but it should be!
> 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.
>
Let's keep it for now because it's the best section we have for the user 
expectations section. We can consider later if the third piece of the 
definition trifecta is going to work ultimately.
>
> 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"?
>
>
Thanks!

-Mallory

>
>
>
>
>
>
> _______________________________________________
> Secdispatch mailing list
> Secdispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/secdispatch

-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780