Implications of a common private keys directory in 2.1

[Carola Grunwald]

Andrew Gallagher <andrewg at andrewg.com> wrote:

>
>> 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.

Nope.

>
>> 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). 

I implemented Whole Message Encryption in 2006, the year when Facebook
went public beyond students. And how old is Memory Hole?

>
>> 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. 

Which relevant information does the single Received: header, describing
the recipient MTA's interaction with the exit remailer, leak?

>
>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.

Not real-time Tor but remailers providing latency. You got it.
 
>
>> 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.

TLS is a real-time server-to-server connection protocol, which PGP
isn't. You can send your PGP message to and fro around the world through
as many servers as you like hiding all your traces thus removing sender
metadata. With TLS you can't.

> 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.

I'm talking about Whole Message Encryption including the complete header
section.

>
>> a line
>> representing the signature status added to the header 
>
>How does this provide the user with any more assurance than DKIM verification?

DKIM doesn't hide the sender's identity from external adversaries who
try to analyse message flow.

>
>> This concept of an enhanced transport security layer
>
>You have not described a transport security layer, but an MTA-to-MTA message encapsulation protocol.

Sounds great.

> I don't see how this improves upon TLS+DKIM.

- In a TLS session the communication partners' IP addresses are public,
moreover the sender domain is published by the receiving MTA by
retrieving its public key from the DNS in order to verify the DKIM
signature. OTOH with my kind of Whole Message Encryption combined with
an asynchronous message transfer providing latency e.g. through
remailers adversaries have no chance at all to link sender with
recipient(s).

- A DKIM signature isn't as robust as an ASCII PGP block. A tiny
in-transit MIME recoding and it's invalid.

- A DKIM signature doesn't take care of the complete message including
all header fields, which WME does.

- The TLS+DKIM combination taken by itself can't fake the size of a
message, WME with random dummy load can.

And so on.

Kind regards

Caro