Early Review of draft-knodel-e2ee-definition-07
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