Implications of a common private keys directory in 2.1

[Andrew Gallagher]

> On 23 Nov 2016, at 03:48, Carola Grunwald <caro at nymph.paranoici.org> wrote:
> 
> But why does a person have to be in control of a signature key? Why not
> a server in the name of a company resp. its employees.

There is no problem having a server in control of a key. Just so long as we understand that the key is now the *server's* key, not the user's. And there's no point in the server having multiple keys when the same information can be conveyed using a standardised header that's signed by a shared key. All you're saying with the signature is "the sender of this email appears to have authenticated to this server using X credentials", where the credentials in this case are equivalent to username/password. 

It sounds to me like you're trying to reinvent DKIM. 

> There's server-to-server security
> provided usually by SSL/TLS, where nevertheless the communication
> partners can't influence the all-knowing servers building the route.

True. But this appears to be unrelated to your proposal. 

> And
> there's true end-to-end cryptography done by PGP/SMIME at the client
> applications, which also leaks valid (envelope) information thinking of
> message size and structure and the enormously talkative header section.

There are ways around this, such as attaching the real message as a PGP encrypted attachment to a generic form letter (as per Facebook), or alternatively encrypting the header values individually (as per memoryhole). 

> and, btw, with --faked-system-time doesn't even
> leak whether it was processed at business hours or at midnight.

But the received: headers of the message will leak this anyway. Unless you configure your mail queue to only run once a day. 

If you are worried about an attacker on the wire doing statistical analysis of your message sizes and patterns of use, you will probably have to go the whole hog and transport over Tor. And even that is no panacea. 

> At the
> recipient's corporate server that mail is decrypted using the
> recipient's key

If the message is being automatically decrypted at the MTA then it provides no more security than TLS. And if we are only encrypting the content of the mail, then it provides less security than TLS, which encrypts everything from the handshake onwards. 

> a line
> representing the signature status added to the header 

How does this provide the user with any more assurance than DKIM verification?

> This concept of an enhanced transport security layer

You have not described a transport security layer, but an MTA-to-MTA message encapsulation protocol. I don't see how this improves upon TLS+DKIM. 

A