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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp