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

[Kjetil Torgrim Homme <[e-mail]>]

to. den 13. 10. 2022 klokka 01.54 (+0200) skreiv Toerless Eckert:
> I recommended to the authors to have a picture with (composite) endpoints,
> a network with observer/attackers in between and a key management system and
> then to say that any use of end-to-end encryption must define well what is
> included in the endpoints.

Surely the idea must be that e2ee makes it impossible for any third
party to listen in?


> To pick up on your example:
> 
> IMHO web-mail can only provide end-to-end encryption if the web-server is part of
> one end-point. Meaning that any of these web-forms where a user communicates
> with participants of that end-point (company) can be end-to-end. And if that
> end chooses to outsource the web-server to some cloud service, it is still
> end-to-end encryption because we have just created a very large and insecure
> endpoint, and a quite uninteresting network piece.

I do not think it is useful to consider such a scenario end-to-end-
encryption, since it is decrypted by the web-mail provider and readable
in plain text by them.  Without qualifications, the two ends of a mail
exchange are the sender and the recipients.

It is not impossible to implement true E2EE web-mail - you just have to
do the decryption using JavaScript in the browser.  This means the
decryption key must also be stored in the browser, typically unlocked by
a master password at the beginning of your session.  E.g., Firefox Sync
uses the master password to allow such a secret to be synced across your
browser instances without divulging the key itself to any third parties
(including Mozilla).  Of course you have to trust their binary not to
contain any backdoors, but we will never solve *that* problem.

> Ultimately, in the same way as one can not simply say "foo is trusted" without being
> more specific, it is equally useless to say "foo provides end-to-end-security".
> The minimun useful statement  about end-to-end-security seems to be
> "foo provides end-to-end-security between <endpoint1> and <endpoint2>", with sufficiently
> good description of the two endpoints or use of well enough established terms for either.
> 

Most SMTP servers also employ end-to-end-encryption (TLS) for each hop
along the way.  So yes, endpoints matter.

Leaving John's musings in here, which are basically saying the same
thing, although more open-ended :)

> On Wed, Oct 12, 2022 at 05:58:25PM -0400, John Levine wrote:
> > 
> > I'm not looking for the answers to these questions, but for guidelines that would let us
> > come up with consistent answers.
> > 
> > Imagine we have webmail, encrypted connection between server and browser, mail encrypted with PGP or S/MIME.
> > 
> > If the mail is encrypted and decrypted on the server, so the server is part of the endpoint, is that E2E?
> > 
> > I have a mail account on a server on which I personally control the hardware and software, one at Protonmail,
> > one at Gmail.  Are the answers the same?
> > 
> > Or assume the encryption is in the browser or phone app.  Does the key management matter for E2E?
> > How about if the key is stored on the server, but the server promises not to use it, only to
> > provide it to the user's browser?  (You can check their 150,000 lines of code on Github to see
> > whether they actually do this.)
> > 
> > I realize this may seem somewhat nitpicky but if we're going to say end to end, we really need
> > a clear understanding of what "end" implies or requires.

-- 
venleg helsing,
Kjetil T.