On Mon, Jan 3, 2022 at 12:22 PM Patrik Fältström <paf@xxxxxxxxxx> wrote:
Hi,
To start with I think it is important to separate "message" from "transport". Then when we have agreed to that distinction (which I claim exists in the IETF) we can discuss securing transport as one thing and securing the message as one thing. And with "securing" I include both signing and encrypting and what not (or choose to do neither).
+1
I am actually using three layers of encryption. Besides message and transport, there is a further level applied when keys and key shares are transported.
If that is the architecture we (still) use, it is I claim easy to see that we can never ever replace the security of the transport with the security on the message.
Absolutely. Transport security is essential to prevent traffic analysis attacks. Most of the surveillance infrastructure in authoritarian regimes is focused on identifying social networks. The message content is secondary.
I am not claiming to build systems suitable for use by dissidents, that takes a much higher degree of attention to detail and steganography.
This at the same time as one can look at implementation of solutions where an end user decides to get the service from someone else to manage the security of the message, and then the communication between the end user and this service should probably be some transport/access which is extraordinary (or rather is some TLS secured transport with some MFA authentication).
If we are dealing with messages in a corporate environment, the messages themselves are not confidential to the corporation. If Alice Trader is sending messages through the trading desk to Bob Customer, those are sent by and on behalf of the brokerage.
In this respect, corporations are people in that this is a communication between parts of the same whole. Past approaches have tended to fall into the trap of rampant individualism which denies the legitimacy of any oversight in any circumstance.
But having identified this as a requirement, the solution is not to just throw in an uber-decrypt key because when we deal with any organization, we have to consider insider threats. Hence the need for threshold control of any decryption shares.
Anyway, I feel the discussion to some degree mixes the integrity and security of a message with the transport. And I want us to remind ourselves that these are two different things.
And many want both...
And we also need to deal with the fact that the SMTP design conflates content metadata and routing headers.
Right now, I am composing in Gmail which due to my SMTP spam problem is the only mail client I can use (like many former anti-spam technology people I have a spam problem that is several orders of magnitude worse than 99.999% of users. At VeriSign I received about a third of the total email sent to the company server.)
Gmail has lots of formatting controls but if I actually use any of them, people are going to be squawking about their teletype machine not being able to work. And despite the fact that HTML is a standard, there is no standard for a subset of HTML for use in email. We should fix that as well and fix things like quoting other emails which fail badly.
--- PHB
