ietf-openpgp
[Top] [All Lists]

Re: [openpgp] Discussion regarding signalling of preferences for multiple encryption-capable keys

2022-04-17 23:03:00
On Sun 2022-04-17 00:47:06 +0000, Greg Maxwell wrote:
On Thu, Apr 14, 2022 at 8:53 PM Daniel Kahn Gillmor
<dkg(_at_)fifthhorseman(_dot_)net> wrote:
The end user wants to see the cleartext!

Under that basis one could argue that whenever unsupported ciphers are
requested the system ought to send cleartext embedded in an pgp
binary/ascii-armored message. ... Silently failing to insecure or less
secure than believed behavior isn't great. :)

That's not my argument (at least it's not the one that you're quoting)
:) I wasn't saying anything about what the *sender* should do.

The argument was: if the user receives data and they *can* decrypt it,
it's very hard for an implementation to justify refusing to show the
user the available cleartext, regardless of what the user's stated
policy has been.

If the message was weakly encrypted, it has already leaked -- the damage
has been done, and not-decrypting it at that point seems like just
gratuitously antagonizing the user.  I grant that some parts of E-fail
make good arguments for how overeager decryption can be dangerous.  We
should definitely defend against those use cases.   But if we just show
the user ciphertext, we're basically forcing them into trying to decrypt
it themselves, with whatever unergonomic tools they have available,
which itself can generate knock-on security issues.

"Your messages are secure, unless some of them happened to be
encrypted without function-bar in parallel, which you wouldn't know
because these messages were silently accepted in spite of your key
requesting otherwise."

I think "your message is secure" should be a distinct signal to the user
from "here is the cleartext of your message".  I'm not claiming that
every MUA does this properly right now, but if it doesn't, it seems like
a bug worth reporting.

If anyone interested in this kind of nuance, I recommend reviewing the
e2e-mail-guidance document over in the LAMPS WG, for example this part
seems relevant:

https://www.ietf.org/archive/id/draft-ietf-lamps-e2e-mail-guidance-02.html#reply-to-errant-encryption

(the doc is framed as mosty S/MIME, but it should be generally
applicable to PGP/MIME).

Regards,

   --dkg

Attachment: signature.asc
Description: PGP signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp