[openpgp] review of draft-ietf-openpgp-persistent-symmetric-ke ys-01

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 to [email protected]