alt Hacker NewsI'll take the hit on the loose phrasing regarding the SSL paper "outlining plans". That was a poor description of mine of an analysis paper and wasn't a good example of the point I was trying to make. However, you are focusing on the trees and missing the forest. The citations you analyzed actually prove the semantic shift I am describing, specifically the MITRE one.
You quoted the MITRE paper (or the older paper it references) defining end-to-end encryption as:
> "data being enciphered at the source and remaining unintelligible until it deciphered at its final destination."
This is the exact crux of the disagreement. In classic Client-Server architecture, the Server was the "final destination". The application processing the data lived on the server. Therefore, by the definition you just quoted, SSL/TLS from Client to Server was "End-to-End Encryption" because the network (routers/ISPs) could not decipher it.
The "modern" definition (post-Signal/WhatsApp) effectively redefined "final destination" to mean "another human user," relegating the Service Provider to a mere hop in the middle. That is a massive semantic shift.
re Saltzer's "End-to-End Arguments": The paper argues that functions (like reliability or encryption) should be moved from the lower network layers (links) to the "ends" (hosts/applications). SSL/TLS is the literal implementation of this argument: moving encryption out of the network links (Link Encryption) and into the application endpoints (Host-to-Host).
The term "End-to-End" in networking *has* historically meant Host-to-Host (Transport Layer), whereas the modern messaging usage means User-to-User. That is why a lot of folks from that era (and the RFCs) called SSL "End-to-End encryption" because relative to the network, it is.
---
RFC 4949 from 2007 (Internet Security Glossary) is quite explicit on this: https://datatracker.ietf.org/doc/html/rfc4949
> $ end-to-end encryption
> (I) Continuous protection of data that flows between two points in
> a network, effected by encrypting data when it leaves its source,
> keeping it encrypted while it passes through any intermediate
> computers (such as routers), and decrypting it only when it
> arrives at the intended final destination. (See: wiretapping. Compare: link encryption.)
>
> Examples: A few are BLACKER, CANEWARE, IPLI, IPsec, PLI, SDNS, SILS, SSH, *SSL, TLS*.
>
> Tutorial: When two points are separated by multiple communication
> links that are connected by one or more intermediate relays, end-
> to-end encryption enables the source and destination systems to
> protect their communications without depending on the intermediate
> systems to provide the protection.
---
RFC 1455 from 1993 (32 years ago) also uses the term in the IP/Host context: https://pike.lysator.liu.se/docs/ietf/rfc/14/rfc1455.xml
> At this time all Internet Protocol (IP) packets must have most of their header information, including the "from" and "to" addresses, in the clear. This is required for routers to properly handle the traffic even if a higher level protocol fully encrypts all bytes in the packet after the IP header. This renders even *end-to-end encrypted* IP packets subject to traffic analysis if the data stream can be observed.
---
Regarding your claim that "no one really used the E2EE term before it got the current meaning," the IETF standards for the internet (albeit an informational RFC and not a standards RFC) explicitly list SSL and TLS as examples of End-to-End encryption. The definition of "End" has simply shifted from the Machine to the User.
> I'll take the hit on the loose phrasing regarding the SSL paper "outlining plans". That was a poor description of mine of an analysis paper and wasn't a good example of the point I was trying to make
I don't understand why you cited it at all; I didn't read it carefully, but I didn't find anything relevant to the discussion.
---
RFC4949 might indeed support your point; it says intended final destination, though: while SSL is listed among the examples, does that include the "SSL-server-SSL" of a non-E2EE messaging system?
I think there's a good chance that it doesn't, in the intentions of the RFC's authors.
---
> This is the exact crux of the disagreement. In classic Client-Server architecture, the Server was the "final destination"
The disagreement is on whether in a user-server-user system, encrypting the two user-server sides was ever considered sufficient to call it an end-to-end encrypted system.
I think it wasn't, and to my recollection, luckily, no one ever tried to call it that.
Keep in mind that it used to be rare both to use any kind of encryption, and to go through an intermediary server for real-time, one-to-one communication.
It's only when centralized messaging systems begun to use SSL that the possibility of confusion arose.
They should just never have called themselves encrypted, in my opinion; encrypting the traffic was sure a big improvement, but I'd only call a messaging system encrypted if no decryption occurs before reaching the recipient
---
> The definition of "End" has simply shifted from the Machine to the User.
The ends are actually machines in the current definition too, it's not like people decrypt stuff by hand ;)
---
You sure proved that E2EE was a term already in use, anyhow (although I don't think too widely)