[E2ee] Fwd: Thoughts on draft-knodel-e2ee-definition

[Mallory Knodel <[e-mail]>]

Hi all,

For the purposes of documenting progress on this draft, I'm forwarding 
this exchange to the list.

Please feel free to comment,

-Mallory



-------- Forwarded Message --------
Subject: 	Re: Thoughts on draft-knodel-e2ee-definition
Date: 	Fri, 7 May 2021 10:35:55 -0400
From: 	Mallory Knodel <[e-mail]>
To: 	[e-mail], [e-mail]



Hi Adrian,

Thanks very much for this early review! And apologies for taking so long 
to respond.

More:

On 2/23/21 5:46 AM, Adrian Farrel wrote:
> Hi,
>
> My immediate thought when I saw your Abstract was, "What is an end?"
>
> So, congratulations on the valiant attempt in 2.1. However :-)
>
> I think you need to recognise two things...
>
> 1. A user is generally assumed to be a human being. You say, "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) as components in a subsystem's design." And that makes me think
> that e2ee means user-to-user encryption, but (subtly) that is not what you
> mean because you do not expect the user to type encrypted emails. I think
> the thing that might help tease this out is to mention "communication
> subsystems". That is, the data that is passed by the combination of 
> the user
> and their applications to the communication subsystem should already be
> encrypted.
>
> That said, I am not sure where something like IPsec sits in that model.
> IPsec is part of the communication subsystem, but can clearly sit on the
> user's device. Are you saying that IPsec is not a tool for e2ee?

We pulled out a new section on end point, though it's hard to do without 
toggling back and forth between the relationship with the other end 
point, eg the e2e principle!

I focus here on why we need to understand user expectations, a later 
section already. So thanks for contributing to the thinking around that.

But I also put in your point about IPSec-- do we want to make sure our 
definition carries water for e2ee supporting protocols? IPSEc might also 
be solved by worrying about tunnels or no tunnels...

> 2. You are, I think, missing the concept of tunnels. Tunnels have ends.
> Tunnels are used to carry trusted traffic over untrusted environments.
> Tunnels have "users" that are normally processes. Encryption on tunnels is
> hugely important to how the Internet works. Now, that may not be what you
> want to talk about in your document, and that's OK, but the feel 
> (partly by
> you talking about end-to-end, and partly by the long preamble about BGP in
> 2.1) is that it is in scope.

Wondering if Fred or Olaf could jump in? I think I would say tunnels are 
indeed out of scope because it's transport encryption, but you're right 
that we talk about BGP. It's only in an attempt to elucidate the end 
point and e2e principle.

Thoughts from my co-authors on squaring this circle?

>
> As an aside, I find section 4 to be mistitled. I think "desire" would be a
> better word than "expectation". Unless you phrase this as "users have a
> right to these expectation". Indeed, if a user truly expected things like
> the provider being trustworthy, they would be far less inclined to use 
> e2ee:
> it is the absence of guarantee of meeting any of these expectations that
> drives the necessity of e2ee.

Again-- it's now much more obvious why we need this section. I think we 
have to keep it somewhat rigorous, where desire is not as such more than 
expectation, and also it's increasingly an industry term in, say, the W3C.

We're putting out a -01 in MLS, so please we welcome reviews there!

Or here: https://github.com/mallory/e2ee/blob/main/draft-e2ee.md

-Mallory

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