Hi Falko and Daniel,
I agree this information should probably go into an optionally critical
subpacket.
I find the notion of requirement is quite hard without using subpackets, since
it is easy to strip a key of a subkey and just pass it on to a recipient,
without the main fingeprint or KeyID changing. It would still pass many
authenticity validations. Therefore we would probably be better off changing
all involved subkeys' subpackets to signal the "requirement" of a multi-key
algorithm, probably in a critical subpacket for post-quantum keys and
non-critical for pre-quantum. This maintains backwards compatibility and avoids
downgrade attacks.
Cheers,
Aron
--
Aron Wussler
Sent with ProtonMail, GPG key 0x7E6761563EFE3930
------- Original Message -------
On Friday, April 15th, 2022 at 10:44, Falko Strenzke
<falko(_dot_)strenzke(_at_)mtg(_dot_)de> wrote:
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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp