ietf-openpgp
[Top] [All Lists]

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

2022-04-15 03:44:49
Hi Daniel,

Am 14.04.22 um 22:52 schrieb Daniel Kahn Gillmor:
right, there are two distinct things a keyholder might want to signal:

- the*capability*: that they can accept a hybrid scheme, and
- the*requirement*: that they*require*  a hybrid scheme.

But, i'm not sure how much the keyholder's preference really matters for
the requirement part -- when encrypting, it's really the sender's policy
that ultimately governs, right?

For example, the sender can always send cleartext, which is arguably
worse than single ECDH.  And if the sender ignores the keyholder's
stated requirement for hybrid encryption, and chooses to just use ECDH
to encrypt a message to a single key that the recipient has, would the
recipient really refuse to decrypt it?  I mean, maybe some would, but
it's pretty hard to convince (for example) a MUA that they shouldn't at
least try to decrypt a ciphertext if they have the key available, even
if it's not their preferred algorithm.

The end user wants to see the cleartext!

I agree in so far as that currently OpenPGP does not model and and does not need to model any similar requirement regarding signalling such restrictions for the use of encryption keys. But I think the post-quantum setting and the transition to it brings in a new aspect. Say Alice is a party aware of the need for secure encryption regarding messages sent to her. She has a PQC encryption and and ECDH key in her public key ring. Say Bob is among the users that send messages to Alice. If Alice wants Bob to use the highest possible degree of encryption, that would be the multi-algorithm combination of the PQC encryption scheme with ECDH. Let's now assume we only use signalling of the *capability* for multi-algorithm (i.e. what you refer to as hybrid) encryption. Bob uses some MUA that uses whatever policy the implementers chose for encrypting the message to Alice based the capabilities signalled in her keyring. This MUA thus chooses on its own one of these possible ways of encrypting the message:

- multi-algorithm combination of ECDH and the PQC key
- only the PQC key
- only the ECDH key
- parallel encryption with both keys

The point that I want to make is that currently with OpenPGP, Alice can restrict Bob to using an encryption key for messages to her by only including encryption keys in her keyring that she considers secure and telling him "send this sensitive data to me encrypted", the latter being an instruction that Bob must be assumed to understand and be able to enforce via the interface of his MUA. In the PQC setting the situation changes, the verbal signal "send it encrypted" just doesn't seem to suffice as it implies too many alternatives the security implications of which the average user will not be able to oversee (he only understands the difference "encrypted / unencrypted") – that is, if he is given any control over these alternatives by his MUA at all. This is specifically relevant if Bob uses a legacy MUA that does not even have a chance to interpret the signalled capability for multi-algorithm encryption at all.

Consequently we would consider it worthwhile to think about introducing the possibility for signalling the *requirement* for using an encryption key only in combination with another. That would simply mean that a conforming client would have to respect that requirement when encrypting.


What would you think about starting with a definition of just the
*capability*  signal as you ramp up this work?  the semantics of the
*requirement*  signal seem pretty ambiguous to me.

I think the actual decision has, if any, only a limited side effect on other design aspects. So I think postponing the decision and using either of the two for now should be fine for us.

Best regards,
Falko

(FYI: I am on vacation for two weeks now, so further responses may be delayed)

--

MTG AG
Dr. Falko Strenzke
Executive System Architect

Phone: +49 6151 8000-24
E-Mail:falko(_dot_)strenzke(_at_)mtg(_dot_)de
Web:www.mtg.de


MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If
you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email. Unauthorised
copying or distribution of this email is not permitted.

Data protection information:www.mtg.de/en/privacy-policy

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

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