Semantics of inclusion of sender's key confusing

[koto]

From coruus@gmail.com on July 06, 2014 23:35:24

Steps to reproduce:

1. Send a message to a recipient and delete the sent message
2. Have the recipient delete her public key, but not the received message

What happens? The recipient now has a copy of the message that the sender can decrypt. The sender does not have a copy of the message TO decrypt, but could decrypt the recipient's copy.

Some thoughts about the right semantics:

A. E2E used with Gmail (or other services with mail-semantics)

If a user is using E2E with Gmail, they know that they are identifiable as the sender of the message. It is therefore appropriate to maintain traditional email semantics by including a readable copy of the message.

It would be better, however, to do so by BCCing the sender on the message, and including a PKESK under the sender's key with this BCCed message -- but not with the message sent to the recipients.

(Otherwise, the situation is confusing: If the recipient deletes her public key, but not the message, and the sender deletes the sent message, but not his public key, the recipient has a copy of the message that the sender can decrypt.)

B. E2E in other browser contexts (cut-and-paste)

If a user is using E2E in another browser context, it should be assumed that they are not using a system with mailbox semantics. The message should not be encrypted to the sender's public key, without explicit indication that this is the desired behavior.

(In particular, consider a potential source anonymously emailing a reporter; it is very undesirable -- and potentially dangerous -- for the sender to be able to decrypt the message. At the moment, because the recipient's public key is included in all PKESK packets, anonymity is violated.)

Original issue: http://code.google.com/p/end-to-end/issues/detail?id=103

[koto]

From koto@google.com on July 07, 2014 09:16:31

I don't quite see the confusion. When using OpenPGP for e-mail messages, it's usually assumed that PKESK to a sender's key is present (for the sender to decrypt the message). This is e.g. how Enigmail works (I think that's a default setting). In my opinion OpenPGP should not be assumed to provide anonymity, but confidentiality and authentication.

"OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures"

[koto]

From coruus@gmail.com on July 07, 2014 12:23:16

Do, e.g., {gpg,pgp} -er 0x00000001 message.txt

No PKESK to the sender's public key is included; there isn't anything to identify a specific sender.

This should be POSSIBLE in the extension. Right now, it isn't. It is impossible to send a message without identifying a key that you have.

Anonymity needs to be the default for copy-and-paste encrypt-only usage of the extension. If the sender wants to be able to read the message, she can always include herself as a recipient.

[koto]

From evn@google.com on July 17, 2014 17:08:12

Cc: tha...@google.com
Labels: Component-UI Usability Security

[koto]

From evn@google.com on July 18, 2014 14:08:25

we could add a chip for the sender, and allow the user to remove it maybe?

it's a bit confusing though.. thoughts?

Cc: r...@google.com koto@google.com

[koto]

From koto@google.com on July 18, 2014 14:15:38

We want to target non-GPG audience, so the default behaviour must be convenient.

I think adding the sender's key by default is OK. We might be more explicit with this (by adding a chip), but we should also warn the user somehow that he won't be able to decrypt the message when to chip is removed. Also when inserting the message back into the website, sender's email address should not be in the recipients list (I don't want yet another copy of my email).

I don't have any problem with leaving this as-is though. I disagree that OpenPGP should guarantee anonymity.

[koto]

From coruus@gmail.com on August 04, 2014 08:18:25

Some proposals:

Compatible symmetric option: Generate a 260-bit secret and store it in the keyring. Encode as base 32, apply S2K to derive a "sent mail" key. When sending a message, instead of generating a PKESK, just generate a SKESK encrypting the session key. (Since it's kind of hard to find OpenPGP software that supports ECDH right now -- this might actually be more useful than the present approach.)

Better asymmetric option: Generate an ECDH keypair which is used only for encrypting sent mail (and treat it as a secret). Encrypt to the sender's "sent mail" key, and set (as permitted by RFC4880 ) the key ID fields to zero. (The nice thing about this is that it that it's then easy to rotate sent mail keys frequently.)

Easy asymmetric option: Just set the key ID fields to zero.

Any thoughts?

[koto]

From evn@google.com on August 19, 2014 12:30:46

Status: Duplicate
Mergedinto: 101

[koto]

From evn@google.com on August 19, 2014 12:31:04

I'll move your suggestions to the other bug coruus.

[koto]

From evn@google.com on August 19, 2014 12:31:19

Issue 101 has been merged into this issue.

Cc: adhintz@google.com

[koto]

From evn@google.com on August 19, 2014 12:31:34

Status: Accepted
Mergedinto:

[koto]

From evn@google.com on August 19, 2014 12:31:46

nevermind, let's use this one

[koto]

From evn@google.com on August 19, 2014 12:32:10

Issue 101 has been merged into this issue.

[dlg-yahoo]

Awesome. Let me update you briefly on the strategy we want to see pursued:

• All sent messages are re-encrypted to a per-message local key.
• These per-message keys are managed by the extension.

It's going to be really hard to provide a solution for sent messages that

• preserves forward secrecy (and drops the correlation between network-sent messages and stored messages),
• and provides an acceptable UX

without moving to this.

[sirdarckcat]

coruus@ can you write a design doc explaining the Forward Secrecy idea and the full changes? so we can comment on that. Explicitly explaining what are the advantages, and whatever information we have to support that.

[dlg-yahoo]

Already in progress; will update this issue with link when available. (It's kind of part of a design doc for multidevice.)

[koto]

Closing this - we're staying with the current behavior. Reasoning - it's the most expected one from an OpenPGP implementation.