Re: [openpgp] Context Parameters for Signing and Encryption

[Marcus Brinkmann <[e-mail]>]

Hi,

According to the meeting notes, there might have been a couple of misconceptions. I don’t know if addressing those could change the outcome at this point, but as there is interest in the topic for the future, I might just as well address these now.

* Key use flags can only give coarse domain separation, not per-message (this was discussed before on the ML).

* If the context is lost, the ability to decrypt depends on how the authenticated encryption is instantiated. With AEAD, the common case is that cipher text integrity is independent of decryption at the implementation level. For example, EAX encryption depends on the key and the nonce, while the associated data is only used to derive the tag. This is also true for OCB and GCM. So, for all proposed AEAD modes, expert tools could implement an „—ignore-tag-failure“ flag similar to ignoring MDC errors, and allow expert users to recover an unauthenticated plaintext independent of the context. Two caveats: Not all crypto libraries support this in their API. And there is no guarantee that an arbitrary AEAD mode allows this, given how the scheme is formally defined (in fact, earlier drafts of our paper had a security proof for a legacy mode where the encryption key derivation included the associated data, and that specific simple instantiation would not have allowed this debug option).

* Anticipating that the PGP community would be uneasy losing control over the ability to decrypt arbitrary files (even those modified by an attacker), in my original email to this list I pointed out the option to include the context string as metadata in the encryption file for debugging purposes. This would be risky for implementers (laying a trap for them to fall into), but it would address these concerns in a simple way, too. And in a certain sense including the original context for recovery is better than ignoring all tag errors during AEAD decryption, because then at least we know the associated data used during encryption (which also includes non-context metadata).

* There was a concern raised by DKG that a signaling mechanism should indicate use of a non-empty context. I have trouble understanding the goal on this one. In the email encryption example, the context policy is part of the email header, and there is no PGP specific signaling mechanism required. In general, trying to decrypt with the empty context will give some indication: If it works, no context was used with probability close to 1. If there is a tag failure, either a context was used or the ciphertext was modified due to a transmission error or attack. That is an implicit signaling mechanism that expresses a single bit. The other extreme case is that the context string is included in the public part of the message, with some risks for implementers as described above.

* As for APIs, Justus expressed concerns that APIs like that of gmime need changes. That is only true if they currently do not have contextualized encryption and want to benefit from a decryption context. Legacy use with an empty context can be supported for any existing API without problems. MIME is an interesting example because MIME has a structure-preserving property: A part is encrypted and replaces its plaintext in situ, preserving the MIME structure around it. This is the basis for MIME wrapping attacks such as Efail direct exfiltration attacks, and also allows an attacker to attack hundreds of intercepted cipher texts in a single email. So, if an implementation wants to protect from these attacks, it must contextualize encryption, which might require changes or at least extensions to its API if the context was not already part of that before. Seen positively, adding a context parameter will make it immediately obvious were in the API encryption is not yet contextualized, and force the required changes to protect against these attacks.

* There seemed to be an overall lack of clarity what is required of OpenPGP to allow applications to make progress on contextualized signing and encryption. I want to suggest a path forward to clarify things: 1. We need a mechanism to express contexts in OpenPGP messages. Only this WG can achieve this, and it is a precondition at least for encryption. 2. We need a namespace for context strings, which should be flexible, because we can not anticipate all use cases in advance. 3. For each application, we need a policy to create context strings that fall into these namespaces.

On 1., specific proposals were made that I think are adequate to address all technical concerns. My hope was that this can be achieved, opening up a way for applications to explore this.

On 2., there has not been a clear discussion of the requirements. But the use cases email (headers) and backups (filenames) suggest that the granularity desired by applications could be very fine. To bring some fresh idea to the table, I would recommend looking at XML’s namespaces using URNs, or alternatively URIs. Both are very expressive and the community has a lot of experience in using these.

If 1. and 2. are done right, I would expect that 3. can be left to the community.

Thanks,
Marcus

—
Dipl.-Math. Marcus Brinkmann

Lehrstuhl für Netz- und Datensicherheit
Ruhr Universität Bochum
Universitätsstr. 150, Geb. ID 2/461
D-44780 Bochum

Telefon: +49 (0) 234 / 32-25030
http://www.nds.rub.de/chair/people/mbrinkmann

> Am 09.02.2023 um 17:48 schrieb Daniel Kahn Gillmor <[e-mail]>:
> 
> On Sun 2023-02-05 12:23:03 -0500, Daniel Kahn Gillmor wrote:
>> we need to resolve whether there will be a context parameter added to
>> the crypto-refresh, for signing, and for encryption.
> 
> In the discussion at the interim today, we spent more time on these
> questions than on anything else.  Thanks for keeping the discussion
> good-natured, despite the lack of unanimity.
> 
> There were reasonable arguments presented on multiple sides of the
> issues, which can be seen at the notes:
> 
>  https://datatracker.ietf.org/doc/minutes-interim-2023-openpgp-01-202302091200/
> 
> Points in favor came mainly from Daniel Huigens: this could work well
> for greenfield applications, and it allows existing applications a
> mechanism that they could use by sorting out coordination and signalling
> at the application layer.
> 
> 
> We held two polls, one for context for encryption and one for context
> for signing, asking whether to include the context parameter in the
> draft without further specification of what its value should be.  Both
> polls had 9 people declare opinions, and they came out with the same
> results for signing and encryption.  Of the 9 expressing an opinion, 2
> supported including context parameters in this draft without further
> specification, and 7 opposed.
> 
> A followup poll, asking who thought this should be tackled by the WG
> after we complete the crypto refresh also had 9 participants, all of
> them in favor.
> 
> My conclusion from the interim is that the consensus here is rougher
> than we'd all like, but we will probably not include an explicit context
> parameter in the crypto refresh.
> 
> I would expect if the WG survives a rechartering, this would be one of
> the top priority items.
> 
>     --dkg
> _______________________________________________
> openpgp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/openpgp