This is an early review of draft-knodel-e2ee-definition-07,
_Definition of End-to-end Encryption_, as requested for ARTART.

This document sets out to provide a definition of the End-to-End
principle (e2e), focussing on necessary conditions for systems to
supply End-to-End Encryption (e2ee), particularly as regards privacy
and security.

Disclaimer: I found this a difficult assignment.  E2e is a motherhood
principle, apparently trivial but in fact bearing a wide range of
interpretations.  Why we need an (informational) RFC defining it is
not clear to me, and the document does little in the way of suggesting
an answer.

But leaving that to one side, it seems to me that although publication
of an informational RFC doesn't imply that it has passed, or could
pass, some practical test of utility, surely it _should_ satisfy its
own stated goals.  In this case that means the provision of "a
generally comprehensible picture of consensus at the IETF as to what
is end-to-end encryption, ... [and] a definition of which specific
security and privacy properties end-to-end encryption should provide "

General: Section 2 and section 3 up through 3.1.1 at least have the
form of a definition, but as far as I can see they barely scratch the
surface.

For example, in the last paragraph of section 2.3, we find:

  [C]reation of pseudo-identities for third parties to allow access
  under the user's identity [is] against the intention of end-to-end
  encryption.

I seriously doubt there is, or could be, consensus on this.  Consider
those (and I know some) who are lucky enough to have a (human)
personal assistant who is the initial recipient of all email sent to
their public email address.  Because I'm familiar with this practice,
I assume that if I were to send email to the head of my institution,
they would not be the first person in their office to read it, and
indeed the response I get may not even be written by them (or at least
not written by them specifically in response to my message and my
message only).  I _think_ the above quote is meant to rule that this
is against the intention of e2ee.  But I can't tell for sure, because
none of what has gone before gives me testable definitions of the
terms involved.

From 3.1.2 onwards the presentation becomes less and less
well-structured and by the end is just a sequence of disconnected
observations.

Conclusion: I couldn't finish reading the draft.  I'm clearly not in the target
audience, perhaps someone with wider and deeper knowledge of the
history of this tarpit would have found some useful observations, but
for me it just raised questions that it did not answer.  

In my opinion it certainly doesn't provide "a generally comprehensible
picture of consensus at the IETF" about e2ee, much less e2e.  Nor does
it provide anything like a usable definition of "which specific
security and privacy properties end-to-end encryption should provide".

I suspect the problem is that by trying to target a general audience
(if that's indeed what is meant by "generally comprehensible") the
authors have fallen between two stools:  not explicit/formal enough to
be of interest to experts, but not clear enough to be of use to
non-experts.

At the risk of flogging a dead quadruped, I think the problem is not
just presentational, but deeply ingrained in the variety and
complexity of relevant practices in the real world.  Returning to my
earlier example, suppose I, in the absence of a human assistant, set
up an out-of-office autoreply in my email client.  Have I violated
e2ee?  Even if my client (unlike some, I guess) implements the
auto-reply without decrypting the message body or ever putting the
sender's human address 'on the wire'?  And so on, this is just the
beginning of a rhetorical arms race of the form "What about this
real-world corner case?  Ah, you have to understand that by "X", we
mean "X, assuming...".  Rinse and repeat.

In other words, I don't see any way to fix the fundamental problem
created by the conflicting goals of formality/explicitness on the one
hand and generality of audience on the other.