Early Review of draft-knodel-e2ee-definition-07
review-knodel-e2ee-definition-07-artart-early-thompson-2022-10-10-00
Request | Review of | draft-knodel-e2ee-definition |
---|---|---|
Requested revision | No specific revision (document currently at 11) | |
Type | Early Review | |
Team | ART Area Review Team (artart) | |
Deadline | 2022-10-03 | |
Requested | 2022-09-25 | |
Requested by | Paul Wouters | |
Authors | Mallory Knodel , Sofia Celi , Olaf Kolkman , Gurshabad Grover | |
I-D last updated | 2022-10-10 | |
Completed reviews |
Secdir Early review of -07
by Derrell Piper
(diff)
Intdir Early review of -07 by Donald E. Eastlake 3rd (diff) Artart Early review of -07 by Henry S. Thompson (diff) Tsvart Telechat review of -07 by David L. Black (diff) |
|
Assignment | Reviewer | Henry S. Thompson |
State | Completed | |
Request | Early review on draft-knodel-e2ee-definition by ART Area Review Team Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/art/639TNrFBMkdrMJvb6Oq6oxz_Z9Y | |
Reviewed revision | 07 (document currently at 11) | |
Result | Not ready | |
Completed | 2022-10-10 |
review-knodel-e2ee-definition-07-artart-early-thompson-2022-10-10-00
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.