Hi,
I assume this draft has been discussed widely in the Security Area, to
have reached last call, but I don't follow discussions there, so I'm
sorry if my comments are repetitive.
These dimensions taken as a whole comprise a generally comprehensible picture of consensus at the IETF as to what is end-to-end encryption,
I'm not sure that we have any real consensus about this. I guess this
last call will tell us.
Instead the end-to-end principle, which is well established [RFC3724] in internet standards
I think, if you follow the breadcrumbs from that RFC, the conclusion
is more that the original e2e principle has been dubious for many years.
RFC8799 (not an IETF document) suggests that the notion of an Internet
that supports the e2e principle as a universal is now history. It really
isn't "established in Internet standards"; I would argue that there are
standards and BCPs that militate against it, and that there are many
deployment mechanisms in use that explicitly don't adhere to it (CDNs
being the most blatant example). When you think you are connecting
to www.ietf.org, you aren't.
Encryption is fundamental to the end-to-end principle.
That simply isn't true. The e2e principle was propounded when "security
considerations are not discussed in this memo" occurred in most RFCs
and line-speed cryptography was a pipe dream.
Certainly the e2e principle would, I think, always have considered
encryption/decryption to be among the "required end-to-end functions
[that] can only be performed correctly by the end-systems themselves"
[Saltzer, et al]. But that's the opposite statement: The e2e principle
is fundamental to encrypted communication.
Example snippet:
Is this a quotation, or what? Incidentally, the [komlo] reference is 404.
Earlier in this document end-to-end encryption was defined using formal definitions assumed by internet protocol implementations.
I can't find the earlier text that does this, can we have a more precise
cross-reference?
the reader can be confident that current deployments of end-to-end encrypted technologies in the IETF indicate the cutting edge of their developments,
That reader would have more confidence in the IETF than I do ;-).
Section 3.2 and all of section 4 seem very aspirational to me but not
in the least surprising, and they don't tell me what I should do
differently in my next protocol design. What should be changed in
RFC3552 (BCP72)? What should the Security Area be doing differently?
Regards
Brian Carpenter
On 11-Oct-22 10:21, The IESG wrote:
The IESG has received a request from an individual submitter to consider the
following document: - 'Definition of End-to-end Encryption'
<draft-knodel-e2ee-definition-07.txt> as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@xxxxxxxx mailing lists by 2022-11-14. Exceptionally, comments may
be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.
Abstract
End-to-end encryption is an application of cryptography mechanisms
and properties in communication systems between endpoints. End-to-
end encrypted systems are exceptional in providing both security and
privacy properties through confidentiality, integrity and
authenticity features for users. Improvements to end-to-end
encryption strive to maximize the user's security and privacy while
balancing usability and availability. Users of end-to-end encrypted
communications expect trustworthy providers of secure implementations
to respect and protect them.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-knodel-e2ee-definition/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
IETF-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
