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

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 Jul 2021 16:07:50 -0700

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"?

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 26 Jul 2021 23:10:48 +0000

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

You might find Alex’s presentation at CFRG useful.

---

From: Mallory Knodel <[email-masked]>
Date: Mon, 26 Jul 2021 19:51:11 -0400

Hi,

> You might find Alex’s presentation at CFRG useful.

I think if we got to this place in the first section, we would summarize 
this concise definition in the abstract of the draft so that it's the 
Very First Thing.

-M

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 Jul 2021 16:50:53 -0700

I took a quick look at his draft and it seems like there is useful stuff
there as well. Perhaps some kind of merger is possible?

On Mon, Jul 26, 2021 at 4:10 PM Salz, Rich <[email-masked]> wrote:

>
>    - Provide a generic definition of what E2EE encryption means

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 26 Jul 2021 23:53:15 +0000

I don't think I understand.  Are you saying that you support a merged doc using Alec's as the new "part one" ?

---

From: Alec Muffett <[email-masked]>
Date: Tue, 27 Jul 2021 00:54:17 +0100

Alas I missed most of Mallory's session (late feed + putting baby to bed)
up-to the point where ekr was asking questions; I'm hoping that I can
catch-up somewhere.

However I just submitted my deck to CFRG, and it's also available at

  https://alecmuffett.com/alecm/tmp/draft-muffett-e2esm.pdf

- I think the deck will help clarify the differences in approach.

     - alec
--
https://alecmuffett.com/about

---

From: Chelsea Komlo <[email-masked]>
Date: Mon, 26 Jul 2021 18:20:34 -0600

Hi Eric,

Thanks for this review; responses specifically for the succinct definition.

>    your state, but presumably I have not violated the defn.

Sure, this is a trivial win condition.  This is considered in the citation
but should be reflected in this draft.

>    In this case, the states don't match, but again we wouldn't

DoS is another trivial win condition; it is considered in the citation and
should also be reflected in this draft. Note that while protocols/systems
should try to protect against this case, it cannot be ruled out entirely.

I'll work with Mallory to make these edits.

Thanks,
Chelsea

---

From: Mallory Knodel <[email-masked]>
Date: Mon, 26 Jul 2021 20:53:10 -0400

Hi,

> I don't think I understand.  Are you saying that you support a merged doc using Alec's as the new "part one" ?

Only commenting on concision: A concise definition would be nice. 
Putting such a concise definition would be best placed as early as 
possible in the text, such as in the document abstract.

However we might belabor the formal definition section such that the 
concise definition is sufficiently built up (eg end, e2e, e2ee) in the 
first section on formal definition.

-Mallory

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Jul 2021 10:12:24 +0000

There are a few challenges with the use of the term "e2e security":
* First, it became a marketing term. Many want to label their solution as something that provides e2e security.
* The end points have different meanings to different people. A VPN is an e2e security solution if the endpoints are the laptop and the VPN gateway.
* There are other security aspects that play a role in the benefits it provides (e.g. who has access to the long-term keys).

Ciao
Hannes

-----Original Message-----
From: Secdispatch <[email-masked]> On Behalf Of Mallory Knodel
Sent: Tuesday, July 27, 2021 2:53 AM
To: Salz, Rich <[email-masked]>; Salz, Rich <rsalz=[email-masked]>; Eric Rescorla <[email-masked]>; IETF SecDispatch <[email-masked]>
Subject: Re: [Secdispatch] Comments on draft-knodel-e2ee-definition-02

Hi,

Only commenting on concision: A concise definition would be nice.
Putting such a concise definition would be best placed as early as possible in the text, such as in the document abstract.

However we might belabor the formal definition section such that the concise definition is sufficiently built up (eg end, e2e, e2ee) in the first section on formal definition.

-Mallory

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

_______________________________________________
Secdispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdispatch
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 Jul 2021 13:45:27 +0200

On 27.07.21 01:50, Eric Rescorla wrote:
> I took a quick look at his draft and it seems like there is useful 
> stuff there as well. Perhaps some kind of merger is possible?
>
Yes, please.  Alec's work seems like a nice, formal, and most 
importantly easily understood approach.  That makes it a great starting 
point.

Eliot

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 27 Jul 2021 13:28:49 +0000

>    * First, it became a marketing term. Many want to label their solution as something that provides e2e security.

That is important, especially if we are trying to win what is a "war of words" against people who can say "lawful intercept"

---

From: Alec Muffett <[email-masked]>
Date: Fri, 30 Jul 2021 03:38:35 +0100

On Tue, 27 Jul 2021 at 14:29, Salz, Rich <rsalz=[email-masked]>
wrote:

> >    * First, it became a marketing term. Many want to label their
> solution as something that provides e2e security.
>
> That is important, especially if we are trying to win what is a "war of
> words" against people who can say "lawful intercept"
>

Hey all; copying from my recent email to CFRG:

I will be presenting "draft-muffett-end-to-end-secure-messaging" tomorrow
at the CFRG meeting*, but my slide deck is packed, it will be late in the
evening in the UK, I'm sleep-deprived from a new baby, and my experience of
Meetecho so far has involved rather a lot of lag.

So I thought I would put in some effort up-front and entirely spoiler
myself. Attached is a YouTube video with my entire slide deck for tomorrow,
and voiceover, running for 9:42s, so at least in theory it is possible for
me to run to time.

https://www.youtube.com/watch?v=QmL9HYywrHg

I am sharing the video openly, and depending on "tech" I may try showing it
tomorrow, reusing the audio, or else I may attempt to "wing it" and repeat
it verbatim, live; but if you're enthusiastic about the draft, you're
hereby invited to prep your slings and arrows by watching the video
beforehand.

    -a