Early Review of draft-knodel-e2ee-definition-07
review-knodel-e2ee-definition-07-intdir-early-eastlake-2022-10-04-00
Request | Review of | draft-knodel-e2ee-definition |
---|---|---|
Requested revision | No specific revision (document currently at 11) | |
Type | Early Review | |
Team | Internet Area Directorate (intdir) | |
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-04 | |
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 | Donald E. Eastlake 3rd |
State | Completed | |
Request | Early review on draft-knodel-e2ee-definition by Internet Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/int-dir/XABuUEWVlAXCgjMAPRQqmJP3HdQ | |
Reviewed revision | 07 (document currently at 11) | |
Result | Not ready | |
Completed | 2022-10-04 |
review-knodel-e2ee-definition-07-intdir-early-eastlake-2022-10-04-00
I am an assigned INT directorate reviewer for < draft-knodel-e2ee-definition-07.txt>. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/. This document attempts to be a high level definition of end-to-end encryption. It is at such a high level that essentially none of the usual INTAREA issues (IPv6, headers/options, fragmentation, tunnels, etc.) are relevant. *Based on my review, if I was on the IESG I would ballot this document as DISCUSS/ABSTAIN.* I have the following DISCUSS/ABSTAIN level issues: The document seems biased towards various cryptographic mechanisms and protocols, such as OpenPGP, when equally functional ones are available. It is littered with questionable statements. It seems to assume e2ee is always public key based; while that is common, a definition should cover the case where secret keys are securely distributed by, for example, human couriers. Why is it that early parts of the document claim "privacy" is a MUST but in the middle and later parts of the document, "privacy" is little mentioned and priacy isn't even defined? Section 4.4: This is too strong. Making source code open source, even if that code can all be perfectly checked, is not an absolute guarantee of the security of the "system". For example, an endpoint could be running inside some sort of emulator that is observing all its actions. Section 4.5: So e2ee systems should magically stay ahead of advances in metadata observation techniques? Below are further issues. I could find a lot more with a little effort. Basically, this document needs substantial re-working. It might be easier to start afresh. *The following are other issues I found with this document that SHOULD be corrected before publication:* The end-to-end principle, as I understand it is about relatively smart end points and a relatively dumb pipes. I do not think that "encryption is fundamental to the end-to-end principle". Many unencrypted IETF protocols take the end-to-end principle into account by minimizing dependency on functionality in the network. I have never seen such a complex, verbose, wandering, and ultimately unsuccessful definition of "end-to-end" as occurs in Section 2.2. Section 2.3 is called "Encryption" but it is really about "End-to-End Encryption". Section 3.1.1: The wording of the definition of "Integrity" is messed up. The first sentence is incomplete. Probably the "must" should be "MUST". Section 3.1.2 implies that "Deniability" is a "desirable" feature, but for some communications, what you want is non-deniability. The option of deniability and option of non-deniability would be desirable. Section 4.3, 2nd paragraph: What is formal interference as in "without formally interfering with"? *The following are minor issues (typos, misspelling, minor text improvements) with the document:* In my experience, the word "comprised" is rarely used outside of patents. This document will be less verbose and easier to understand if occurrences of "is comprised" are replaced with "consists". Section 2.2, page 6: "on that all end sub-identities are under" -> "on all end sub-identities being under" Section 3.2, first paragraph: reads like marketing. I don't think saying "deployments ... in the IETF" is right. The IETF does specifications, not deployments. Suggest dropping this paragraph. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com