On Fri, May 16, 2014 at 6:01 AM, <tpb-crypto@laposte.net> wrote:
pesky to/from/subject/etc headers.
Those are hidden by use of TLS.
weaknesses intrinsic to SMTP discussions? Yes, they are hidden in TLS transport on the wire. No, they are not hidden in core or on disk at the intermediate and final message transport nodes. That's bad.
There is no way to hide metadata because you need a destination for your messages to arrive ... has to find its destinations to deliver its contents.
I generally meant TLS hides the multitude of headers, but headers themselves are not today encrypted to the recipient or to the network, so they end up sitting in the open... and their SMTP style and purpose totally unnecessary to a new transport network. Yes of course... the minimum necessary for delivery is the destination address. If the network design ends up yielding control protocol returned from the network to the sender, the source must be present. Your network client node handles decrypting the content to find enclosed within (or to configurably affix if missing) any further traditional headers if needed by your local messaging agent, routing stack, etc. Such content may contain the unique address key of your correspondant, be signed by them, etc. Dest: unique destination address key Optional network metadata: ... Src: optional unique src address key if control feedback Content: encrypted blob 'Optional network metadata' may be needed depending on the network design, full of sigs, routing, storage or other data. But it most certainly won't be SMTP headers as we know them today. And will be encrypted to shield from all but the most minimum of nodes possible. Further, if the network ends up being general purpose bidirectional, such that you might run IP traffic/apps over it, the source address key will obviously be required in either the Src or Content contexts.