Reviewer: David Black Review result: Not Ready This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. This draft sets out to provide a definition of end-to-end encryption for secure communication systems. That is indeed a worthy goal, but the fundamental problem that causes this review to report the draft as "Not Ready" is that Section 2 strays far and wide from that focused goal, and gets things seriously confused in doing so. That alone is sufficient to render this draft not ready for publication. The problems in Section 2 include: - At various points in Section 2, an "end point" is defined as (a) an end user, (b) an identity and (c) the well-understood concept of communication end point in a communication system. Needless to say, those are three distinct concepts, so implying that they are one and the same is seriously confusing, and not helpful to the reader. Only the latter (c) should be used. An identity (b) is a property of an end point, and the attempt (a) to use RFC 8890 to conflate the concepts of end user and communication end point does not hold water. RFC 8890 does support including the end users as elements in the design and analysis of any communication system, but that RFC does not declare end users to be end points - in fact the term "end point" is nowhere to be found in RFC 8890. - Starting in Section 2.1, there is text that appears to redefine the concept of end points in the end-to-end principle and even redefined the end-to-end principle itself as stated in RFC 3724. While this was almost certainly not the authors' intent, that text is not acceptable. - The discussion of sub-identities is towards the end of Section 2.2 is just plain wrong, e.g., as the discussion applies to none of the three examples. The problem is not an exposed gap between the identity and a sub-identity of the end user, rather the problem is that the "tunnel" (which is not a good term to use in this context, BTW) is not end-to-end between end points whose (sub-)identities are identities of the end users involved. In each case, problems arise because one of the two endpoints of the "tunnel" is not associated with the end user who is at the other end of the communication. Having reached the proverbial "three strikes" against Section 2, I'll stop here. The only portion of section 2 that is reasonable to publish in its current form under the IETF's good name is the concise adversarial definition of end-to-end security in Section 2.4. Beyond Section 2.4, I would encourage the authors to focus on revising Section 2.3 to provide a solid functional definition of "end-to-end encryption" without attempting to (re) define either "end-to-end" or the associated concept of "end point" outside the context of end-to-end encryption - the attempts to do exactly that in Sections 2.2 and 2.1 (respectively) are seriously flawed (see above). There's plenty to be done here, e.g., as the first sentence in Section 2.3, "Encryption is fundamental to the end-to-end principle." is incorrect as written because the end-to-end principle encompasses designs of numerous systems that use no encryption whatsoever. Finally, Section 3.1's use of the word "Features" is wrong - those are "Security Properties", and that is the appropriate term to use. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
