Yes, I'm satisfied with the evidence presented that the "major" vendors aren't signing their zones, but I do think we're far off-topic at this point as to whether or not the client IP address has value in the message headers.
The fact is that almost none of the communications we use on a daily basis are end-to-end encrypted. What response would you get if you told staff, partners, executives, support personnel, etc that the new standard was based on GPG web-of-trust or hierarchical S/MIME emails and that all plain text emails (or any not digitally signed) were going to be binned at the mail servers?
For that, I don't blame organizations for doing what they had to do - it's perfectly reasonable. But the discussion that results from this is mostly healthy. Zoom will suffer from the PR but I think that will give us better options as a result going forward.
The problem for the mob rests on the fact that they advertise the system as being e2e, when it is not - at least with the definition I use for e2e. https://zoom.us/security
My rule-of-thumb (NOT A LITMUS TEST) for e2e is as follows: If you have exchanged the public or pre-shared key(s) with the partner(s) out-of-band OR you had your public key signed by a NEUTRAL (key word) third party who is mutually trusted, then yes - you are likely using e2e.
If Zoom generated the keypairs, signed them, and transported the public keys themselves without an external independent library - I don't consider that e2e because they are the middle man every step along the way.
Should we treat other companies the same way if they claim they use e2e but don't? Yes, absolutely. This situation is bittersweet, it's (a bit) unfair to Zoom, but hopefully this will spark healthy discussions around what e2e is and more importantly, what it is not.
Thanks for the link, that's quite interesting. While web browsers can implement their own DNS resolver, that's completely irrelevant when we're talking about an MTA. The server(s) the MTA(s) are running on have their own underlying resolvers which can be DNSSEC-compatible, or better yet, if you're using a public resolver like quad9, they validate the DNSSEC for you.
Edit: Not that I'm saying you should trust quad9 full-stop, but it is a nice feature. Anyone could run their own private resolver but most choose not to because of the very same privacy concerns we're talking about in these headers, namely - making your traffic easier to profile.
I'm not sure what you mean by the "transmitted data itself is not encrypted". The payload (the packet above layer 5) is encrypted. The distinction people need to make is who the _confidentiality_ applies to. The communications are not confidential between the callers/callees. The communications are only confidential between Zoom servers and the users. The provider sees all.
I think you understand this but maybe you didn't word it quite correctly. Never confuse confidentiality with encryption is the take-away that we as an industry need to do a better job telling our users about.
Edit: Well the communication isn't ONLY confidential between users & zoom but I'm simplifying for point of brevity.
Trouble being that SPF and DKIM only work when they've been implemented correctly and they rely on DNS. That requires DNS to be resilient against attacks (DNS isn't foolproof).
While yes, email has no implicit authentication and forging an email is trivial, pulling that attack off is super difficult due to modern SPF and DKIM mechanisms. I'm not super familiar with DKIM but I'll use SPF in my example below.
Let's say I'm running an email server for myself for example.com and I receive an email from 192.0.2.1 and it claims to be from [email protected]. Okay, great. First I consult with my database of blacklists to make sure that 192.0.2.1 isn't blacklisted. If it is, into the trash it goes.
The blacklist reports the address is clear, I move to the next step - SPF. I do a DNS lookup for the txt records under gmail.com and find the one for SPF. But lo and behold, the SPF record does not include 192.0.2.1 as a valid address to submit mail on behalf of gmail.com - this email is likely forged. I drop the mail and submit a report to my favorite blacklist provider(s).
Now, could the DNS have been forged? Yes. With modern DNSSEC, is that likely? I don't think so. Could the packet's source address been forged? Yes, that's pretty easy if you're the ISP or state-sponsored. But if the source address has been forged, there's no way the IP address in the SMTP headers are going to do you any good - the attack is too sophisticated at that point.
If a receiver of mail fails to properly validate the source of the email, that onus is on them as far as I'm concerned, especially so if DNSSEC, SPF, DKIM, etc have all been implemented. While open relays aren't extinct, they sure are easy to detect and most best practices I've read on email say to reject them when detected.
I still don't see how having this trail of user IP addresses is useful. There's nothing implicitly in the message that can be trusted - that's what PKI is for.
I'm not looking for an argument, I've never noticed this behavior before. Why is this done? People are saying this is some kind of way to combat spamming/spoofing/malicious email but I don't see how that's the case. If the source address of the packets matches a blacklist then you can correlate against that. While not impossible to forge an IP address, it's certainly more trivial to edit the SMTP header (I'm not saying that would avoid detection, mind you).
What benefit do we gain from including the origin's IP address throughout the entire header history?
Can someone break down what this means for me? I'm assuming an example of say Thunderbird as the MUA connects to gmail's servers with SMTP over TLS or using STARTTLS and happens to include this header of the client's public OR (not xor) private IP address as per specification(s).
What's unclear for me it whether this is then stripped by gmail's MSA/MTA before being routed towards the destination. From how I'm reading the article in the OP, it seems to imply that the recipient of the message would know the sender's IP address. If this is the case then I'd say that's of some concern, but it seems people are saying this is NOT the case. Can someone please expand on the exact test setup?
Thanks for the discussion!