[openpgp] Re: review of draft-ietf-openpgp-persistent-symmet ric-keys-01

Hi Daniel,

Am 19.08.25 um 15:52 schrieb Daniel Huigens:
> Hi Falko,
>
> Thanks a lot for the thorough review of the draft, and apologies for 
> the long delay in this response.
>
> From your and other responses, it seems like the inclusion of HMAC is 
> useful enough to be kept. However, you're right that there are some 
> risks, so we should be careful in how it's used.
>
> In particular, I had not imagined that email applications should 
> replace asymmetric signatures with symmetric ones upon receipt of a 
> signed email. You're right that doing so naively would lose information.
> Rather, I had imagined that the email application could create an HMAC 
> signature attesting to the fact that the asymmetric signature has been 
> verified (if that's the case).
> Then, in the future, when opening the email again, verifying the HMAC 
> signature could be enough to show the email as verified, without 
> having to verify the asymmetric signature again. (There's then an open 
> question about what to do if the original signing key has been 
> hard-revoked, though.)

How would the attestation happen technically exactly? The mere fact that 
one signature wraps the other would in my understanding not imply the 
semantics that you describe. As long as that is not specified anywhere, 
one client might create HMAC signatures with a different goal in mind 
than another client interpreting them.

Any ambiguity of an HMAC signature would have to be ruled out. Take for 
instance the case where an HMAC key is used for communication and is 
shared between Alice and Eve. If Eve makes up an invalid signature for a 
signature key of Bob, applies an HMAC signature to it (in what ever way 
that you have in mind for the use case of storage MAcing), and sends it 
to Alice, how would Alice's client then know that it must not show the 
message as validly signed?

I think the draft needs to address the security considerations that 
apply to introducing HMAC as a signature scheme. It is just not 
equivalent to asymmetric signatures.

>
> However, for this particular draft, my intention was to provide a 
> number of building blocks, rather than specifying how exactly they 
> should be used in the case of email or any other use case.
> So, I would propose that we indeed mention the security tradeoffs and 
> semantic differences with asymmetric cryptography in the security 
> considerations, but not necessarily outline how symmetric cryptography 
> should be used for specific use cases.

If these building blocks are introduced, then at least clients will need 
to know the rules for when to indicate a message as validly signed by a 
symmetric mechanism.

> The same goes, in my view, for communication using symmetric 
> cryptography: if this is useful for a given use case I don't see a 
> reason to forbid it, and we could mention it as a potential use case, 
> but I wouldn't specify how to do so exactly.

As I argue above, there are interactions between the use cases of 
applying MACs to stored files/mails and communication.

Best regards,
Falko

>
> I will send a separate email about the topic of packets versus 
> algorithms :)
>
> Best,
> Daniel
>
>
> On Tuesday, July 29th, 2025 at 17:22, Falko Strenzke 
> <[email protected]> wrote:
>>
>> I made a review of draft-ietf-openpgp-persistent-symmetric-keys-01 
>> <https://datatracker.ietf.org/doc/draft-ietf-openpgp-persistent-symmetric-keys/01/>.
>>
>> First of all, I want to say that in my view, the persistent symmetric 
>> keys, that this draft proposes, are a very useful security feature, 
>> for a number of reasons:
>>
>>   * Symmetric re-encryption of traditionally (non-PQC) encrypted
>>     messages brings protections against quantum attackers in a
>>     resource-efficient way.
>>   * It generally provides increased strength for the protection of
>>     the confidentiality of messages. This is due to symmetric
>>     algorithms being generally believed to be less prone to a
>>     substantial weakening by new attacks. It thus can provide an
>>     improvement over the storage of public-key-encrypted messages
>>     generally.
>>   * The new packets might also improve on the use of symmetric
>>     encryption for communication. But for now it remains unclear to
>>     me, in how far the draft suggests this use. More on that follows.
>>
>> In summary, I don’t see any fundamental blockers to the 
>> specifications made in the draft. Nevertheless, in the following I 
>> will point out potential problems with the proposed use of HMAC for 
>> symmetric “signatures” and the need for clarifications and coverage 
>> of topics that are currently not addressed.
>>
>>
>>       HMAC and symmetric “signatures”
>>
>> First I would like to point out the benefit as well as a number of 
>> potential issues arising from the proposed use of HMAC for what the 
>> draft refers to as “symmetric counterpart to digital signatures”.
>>
>>
>>         Usefulness of HMAC
>>
>> To specify HMAC for symmetrically “signed”-only messages would be 
>> useful for protecting the integrity of messages without requiring 
>> encryption. Encryption also always entails the risk of loosing access 
>> to the message when loosing the encryption key. Accordingly, there 
>> would be a benefit for a user who only wants to protect the integrity 
>> of messages using a symmetric algorithm.
>>
>>
>>         Loss of sender information and non-repudiation in a signed email
>>
>> Assume that Alice is re-signing a public-key-signed but unencrypted 
>> email from Bob through her HMAC key. Afterwards, her email client 
>> would have no way to securely identify Bob as the original sender. 
>> The original public-key signature was bound to Bob’s email address, 
>> while the HMAC-protected message is associated with a key of Alice 
>> only. I think the draft needs to give guidance for implementers how 
>> to display the signature status of such messages.
>>
>> When Alice re-signs a message from Bob, also the cryptographic 
>> non-repudiation guarantee of the digital signature is lost. This must 
>> be clear to implementers and users. Also here it remains unclear in 
>> the draft, how a mail client should signal this to the user. Guidance 
>> for implementers is needed here as well. Security considerations are 
>> needed.
>>
>> On this background, it is unclear to me how an email client is 
>> supposed to display a symmetrically re-signed message to the user. 
>> Should it show the message as signed? How is it prohibited that user 
>> is not mislead by implying the security guarantees of a public-key 
>> signed message? The draft needs to clarify this in my view.
>>
>> The draft’s claim of “equivalent security” of the symmetric 
>> algorithms in the introduction should also be clarified with respect 
>> to the loss of non-repudiation and the loss of sender information.
>>
>> If HMAC was removed from the draft, the symmetric-re-encryption-only 
>> option would prevent the above problems when not indicating the 
>> messages as signed.
>>
>>
>>         HMAC-only-protected messages breaking of workflows and
>>         architectures
>>
>> A symmetrically “signed”-only message has great potential to require 
>> substantial changes in the OpenPGP layer and client applications. 
>> This is because for the verification of a MAC the private key is 
>> needed, whereas the public-key counterpart requires only the public 
>> key. For instance the frontend/agent architecture of GnuPG would 
>> require substantial redesign to enable the verification of HMAC 
>> signatures. Email clients would generally require changes to both the 
>> OpenPGP and user interface: The OpenPGP library would need access to 
>> the private key for the signature verification and the user might 
>> have to be prompted for their password, etc.
>>
>> Note that symmetric re-encryption doesn’t exhibit the analogous problem:
>>
>>   * Only one of the users clients must be able to symmetrically
>>     re-encrypt the messages. Only this client has to be modified to
>>     using the private key during encryption, which is not the case
>>     for public-key encryption.
>>   * All other “passive” clients that only read the encrypted messages
>>     will require the private key as usual when displaying the message.
>>
>>
>>       Retention of signatures
>>
>> The protected sender address and the non-repudiation addressed above 
>> is not the only information that is lost when dropping signatures. 
>> For instance also the signing time and the information about the 
>> signature algorithm is lost. If the motivation for using persistent 
>> symmetric key encryption on a signed message (encrypted or 
>> unencrypted) is enhancing security, and not necessarily concern about 
>> storage space, the option of retaining the signature and 
>> symmetrically (re-)encrypting the signed message is the optimal 
>> choice. In my view, the current specification allows for this option 
>> but doesn’t explicitly mention it. I think the draft needs to 
>> explicitly address this option to explicitly allow or forbid it.
>>
>> On the background of this option, it would also be useful to include 
>> in the ciphertext meta data the information of the time of the 
>> symmetric re-encryption. In the case of a later publication of the 
>> vulnerability of the signature algorithm, the re-encryption time 
>> would serve as an indication whether the signature was “frozen” early 
>> enough to consider it as having been produced at a time when the 
>> signature algorithm was still secure.
>>
>> In the case of dropping the digital signature in the course of the 
>> re-encryption, it might be useful to optionally include the details 
>> of the signature (algorithm, fingerprint, signing time, etc.) 
>> optionally in the ciphertext meta data for the same reason.
>>
>> Such ciphertext meta data would require the definition of a new 
>> packet type, though.
>>
>>
>>       Use for communication
>>
>> The draft neither explicitly forbids nor allows using the persistent 
>> symmetric keys for communication. This point needs clarification in 
>> my view. A GitLab issue 
>> <https://gitlab.com/twisstle/openpgp-persistent-symmetric-keys/-/issues/1> 
>> about this already exists.
>>
>> I personally think that allowing communication could be useful. 
>> Password-based symmetrically encrypted messages are currently 
>> supported and the new mechanism seems to significantly improve on 
>> that by allowing to shift the task of the key management to the 
>> user’s key ring.
>>
>>
>>       Migration considerations
>>
>> In my view the draft needs to address the safe migration to using 
>> persistent symmetric key encryption on a message store. In the 
>> prominent email use case, this cannot simply be realized as a 
>> straightforward one-shot operation without an undo-option. In case 
>> one of the user’s clients cannot read the new format, the user must 
>> be aware of this beforehand. Accordingly, I would imagine the text to 
>> present a safe migration workflow that allows to test 
>> interoperability of all clients for reading the re-encrypted messages 
>> before the actual re-encryption of the messages takes place.
>>
>>
>>       Guidance on the chosen key size
>>
>> Some guidance on the chosen symmetric key size would be useful. 
>> Saying that for PQ-security, 256 bit is the appropriate choice would 
>> suffice in my view.
>>
>>
>>       Security Considerations section
>>
>> I think from the above it becomes clear, that there are some subjects 
>> to cover in the security considerations section. In my view, this 
>> section should address all relevant security concerns. Those that are 
>> addressed in other places should at least be mentioned there by 
>> reference.
>>
>>
>>       Packet types
>>
>> In the presentation at IETF 123, Daniel mentioned the possibility of 
>> introducing new packets instead of renaming the old ones (I assume 
>> this pertains to keys and the Signatures and PKESK packets). I could 
>> imagine that renaming the existing public-key packets could indeed be 
>> a bit of too big deal for a mechanism that might not be widely used. 
>> From the security perspective, I don’t see a problem either way.
>>
>> It would be good to hear more opinions on this topic.
>>
>>
>>       Summary
>>
>> As a summary, I don’t see any technical point with respect to which 
>> the draft requires revision. All possible options and changes I give 
>> here are merely suggestions. However, all the missing guidance, 
>> clarifications, and security considerations that I point out should 
>> be addressed in my view.
>>
>> - Falko
>>
>>
>> -- 
>>
>> *MTG AG*
>> Dr. Falko Strenzke
>>
>> Phone: +49 6151 8000 24
>> E-Mail: [email protected]
>> Web: mtg.de <https://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: Privacy policy 
>> <https://www.mtg.de/en/privacy-policy>
>>
>
>
> _______________________________________________
> openpgp mailing list [email protected]
> To unsubscribe send an email [email protected]
-- 

*MTG AG*
Dr. Falko Strenzke

Phone: +49 6151 8000 24
E-Mail: [email protected]
Web: mtg.de <https://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: Privacy policy 
<https://www.mtg.de/en/privacy-policy>

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]