Re: [openpgp] Encryption and signature context parameter (Was: OpenPGP encryption block modes)

[Marcus Brinkmann <[e-mail]>]

Hi,

I agree with DKG that these points are all worthy of consideration. I also agree with a lot of what Daniel says, and will just offer some additional clarification in a few places.

Up front I want to emphasize how rare it is for us (in our research group) to publish a constructive paper on a countermeasure, rather than an attack paper. The reason is that Efail included two attacks, malleability gadgets and direct exfiltration. And while malleability is relatively easy to solve with authenticated encryption, we found that direct exfiltration could not be fixed conclusively by implementers. In fact, several attempts were made by email clients to close direct exfiltration mechanisms. Several times we found bypasses in their countermeasures. In 2019, we published another paper [1] with covert content decryption oracles. And although these attacks were mostly mitigated, in 2020, a student of us (Heike Knobbe) reevaluated the study and again found new bypasses and vulnerabilities [2].

This experience strongly suggested to us that we need another approach. This is why Jörg Schwenk suggested to use the „AD“ in „AEAD“ to add strong context separation to email encryption [3], which lead to the suggestion to add a decryption context to OpenPGP. This approach can prevent decryption in a dangerous context cryptographically, which makes a big difference. I will pick up this distinction below when reflecting on protected headers. But it is worth pointing out here that this proposal is not based purely on theoretical cryptographic concerns, but actually is rooted in practical experience with email security.

And it is not just us. Last week, a new clever attack on Thunderbird was published by Sarah Jamie Lewis[4] that bypasses javascript-filters in Thunderbird when in compose mode to leak decrypted plaintexts to the attacker. This would have been prevented by strong context separation.

[1] J. Müller, M. Brinkmann, D. Poddebniak, S. Schinzel, J. Schwenk. Re: What’s Up Johnny, Covert Content Attacks on Email End-to-End Encryption. https://arxiv.org/pdf/1904.07550.pdf
[2] https://research.hisolutions.com/2021/01/von-decryption-und-signing-oracles-covert-content-angriffe-auf-e-mail/
[3] J. Schwenk, M. Brinkmann, D. Poddebniak, J. Müller, J. Somorovsky, S. Schinzel. Mitigation of Attacks on Email End-to-End Encryption. https://nds.rub.de/media/nds/veroeffentlichungen/2020/12/06/schwenk2020.pdf
[4] https://twitter.com/SarahJamieLewis/status/1577745743267631104 <https://twitter.com/SarahJamieLewis/status/1577745743267631104>

> Am 12.10.2022 um 11:17 schrieb Daniel Huigens <[e-mail]>:
> 
> Hi dkg,
> 
>> It's very tempting and elegant feeling to try to apply these sorts of
>> ideas across both primitives, but often they are subtly different. Are
>> we sure that this is important for boh signatures and encryption?
> 
> I think it's fairly symmetric. For both signing and encrypting, using a
> context ensures that the resulting message can't be used in a different
> setting. For both verifying and decrypting, it ensures that the message
> was created in the expected setting.

Yes, and I am glad that Daniel raised the issue of signatures early in the discussion. In both cases, you can not get the same effect with existing mechanisms, because the critical step (verification of the context) can not be done atomically with the Verify() or Decrypt() operation. However, I still think there is a difference:

For signatures, lacking context support in OpenPGP, adding application specific headers to the data or hashed subpackets is possible, but the verification of the signature will succeed independent of the context. The context can only be verified in a separate step, which allows for a larger attack surface when it comes to implementation bugs. (It has been suggested here that the context also needs to be included in the message, but that is not quite correct, as it would be possible to only include a cryptographic hash - although I do not think that this would achieve anything of practical value).

For encryption, lacking context support in OpenPGP, I don’t even know what to suggest. I don’t know of any method to add context separation to decryption without adding it to the decryption itself in the form of AEAD. I guess what comes closest is sign-then-encrypt, if the encryption has at least plaintext integrity. Then you can verify the signature and get some limited context that way. But this is quite heavy-handed and specific to applications like email, where we have decades of experience now that this approach doesn’t work.

So, I do think there is an important difference when it comes to standardization. For signatures, it is at least theoretically feasible for applications to get domain separation in the signed data (e.g. headers) or the signed metadata (signature sub packets). For encryption, the application can not extend the AD field during encryption or decryption, unless the OpenPGP standard explicitly allows for that, and currently it does not.

>> From the verifier's perspective, the verifier needs to know a specific
>> context (and confirm it against the provided context). but if they do
>> that, then they could also just as well know of a specific arbitrary
>> extension that they require to be present on all signatures in that
>> context.
> 
> This is sort of true, but this makes it similar to passing along the
> context with the message (but instead it's in the signature).
> The nice thing of the context parameter is that it doesn't have to be
> passed, which means it doesn't add overhead, and it forces the
> recipient to re-compute the context. With a notation, they might simply
> forget to check that it matches the actual setting.

+1

>> So i'm left with the sense that if we want the security gains from this
>> that aren't otherwise already available (e.g. with Intended Recipients,
>> or with notations), the context should not travel with the object, but
>> rather needs to be explicitly defined by both the producer and consumer
>> of the object.
> 
> Yes, I agree.

+1

>> For this to be useful, an application needs to be able to identify the
>> context that it will use. But what is the context? i mean, it's a
>> bytestring, but what kind of scope should the context have?
>> 
>> !214 uses "Message from Alice to Bob" as a context string. But why that
>> level of detail? Why include both Alice's name and Bob's name? If
>> we're including Alice and Bob's names, why not include the Date and
>> Message-Id as well? If the context string needs to be known a priori
>> and not travel with the message, then we should just use something
>> like "e-mail message" -- if we want to ensure that e-mail headers are
>> cryptographically protected, that's a distinct project [0].
> 
> It's application specific, and we'd need a separate spec to say what the
> context should be in an email setting, indeed. There's a concrete
> proposal for what the context should be in an email setting in [1].
> 
> [1]: https://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2020/12/06/schwenk2020.pdf

We do think it is a good proposal, but we also understand that we can not possibly anticipate all possible issues when it comes to actually deploying strong context separation even within just email, so we think that our proposal is only the beginning of a discussion, not the end of it. However, there are some good aspects:

* Fine-grained email context separation can prevent efail direct exfiltration attacks even within a single protocol (i.e. decrypting an email using an email decryption oracle).
* The actual email headers to include are sender-controlled, so they can be adjusted in strengths vs. compatibility.
* We evaluated for false positives, and found good compatibility even with strong isolation. Btw, the (well-known) problems with outlook should be reevaluated, as I heard some good news that they are no longer breaking OpenPGP messages (but didn’t confirm).

Even just using something like „email“ can prevent some attacks across protocols. In fact, it is useful to compare the situation with TLS, although it is a very different protocol. In TLS, encryption contexts are included in every single key derivation within the handshake, as is good cryptographic practice nowadays (primarily motivated not by attacks but by the need to find security proofs). However, with TLS authentication, we found a lack of context separation that we could exploit in cross-protocol attacks, for example redirecting a web browser to an email server (see https://alpaca-attack.com <https://alpaca-attack.com/>). For TLS, authentication separation can be achieved with the ALPN extension, which is a simple protocol identifier (like „ftp“, „http“). Note that this is an extension similar to OpenPGP’s „hashed subpackets“ and has to be verified manually. This is good for backwards compatibility, because old implementations can ignore it, but of course we find that one year after disclosure almost all servers do not check it and are still exploitable. I should also note that in the context of TLS such a coarse separation, while very helpful, does not prevent all possible attacks (see last two paragraphs of Section 9, „Countermeasures“, in the ALPACA paper).

> I think the nice thing about including the sender and recipient
> (and yeah, the Date and Message-Id could make sense as well) is that it
> ensures that you can't, for example, send someone a ciphertext you got
> or intercepted from someone else, and hope that they reply to you with
> the quoted message. This protection works even in the absence of
> signatures, and is also slightly different from ensuring that the
> headers are protected. Nevertheless, it's possible that protected
> headers would also partially solve it - but it again doesn't force the
> recipient to check the context. Though, if the metadata from the
> protected headers determine what's shown to the user, it might end up
> being equivalent. This mechanism is meant as a general mechanism for
> all applications, though, to encourage them to use it from the start,
> and avoid the need for all applications to solve this.

This is true, but there is IMO a more serious concern with protected headers: Because they can only be parsed after decryption, we are already exposing the plaintext to the risk of direct exfiltration attacks in the presence of implementation bugs. This is why from my point of view having access to the AD in AEAD is so important.

> It's also worth noting that currently, for an encrypted message, *any*
> encrypted message can be decrypted as a valid email, with PGP/Inline.
> So, if another application starts using OpenPGP, it can't protect
> against these types of attacks. *Every* application needs to require
> some kind of application-specific format or signature notation or
> similar, for there not to be any vulnerabilities. This context
> parameter provides a way for new applications to be immune to these
> vulnerabilities, regardless of whether we figure out a transition path
> for email or not.

The symmetry between encryption and signing is also applicable here. For example, any Inline PGP attachment is also signed as-is, without MIME headers. This could be used as a signing oracle in a phishing attack. And I am a bit concerned that for example MIME headers look a lot like Git commit objects, protected headers, etc. They are all based on key + colon + value lines. This is an accident waiting to happen.

Thank you for pointing out the „immunity“ argument. When we disclosed ALPACA, this was the hardest thing to get across in the disclosure process. Context separation not only protects your own context and protocol, but potentially also all others. We found this to be true in the context of TLS, and it is likely applicable here, too (even though I don’t know about any specific attack at this point).

>> Would this be something that works for the deployed base, or would it be
>> something that is only useful for greenfield implementations? Is there
>> a phase-in plan?
> 
> [1] provides a transition plan for email, which would involve adding a
> header to indicate that a context was used (and how to compute it).
> 
>> For example, can we imagine an OpenPGP-capable MUA that one day says "i
>> will not decrypt any message that does not use the 'encrypted e-mail'
>> context string, and i will not validate any signature that doesn't have
>> the 'signed e-mail' context string" ? or would it realistically just
>> continue to accept things that have the null context? if it does both,
>> does it need to do repeated trial decryption and trial signature
>> verification?
> 
> There does need to be a way to deterministically (in advance) compute
> the context, otherwise it somewhat defeats the purpose - so we should
> try to avoid the need for repeated trial decryption and verification.

Yes.

>> Could we tie such a requirement to the version of the OpenPGP object?
>> For example, a MUA that permits decryption of v1 SEIPD without a
>> context, but it tries to decrypt v2 SEIPD, it will only do so with an
>> 'encrypted e-mail' context? or, when it verifies a v4 signature, it
>> ignores the context, but it will only verify a v5 signature under
>> context 'signed e-mail'. Does this seem plausible?
> 
> Yes, I think that would be plausible. If we make the API such that,
> when decrypting or verifying, the context is ignored for v1 SEIPD and
> v4 signature packets, since they don't have one, then the application
> could always compute and pass the context, with an equivalent result.
> 
> (Though - one could argue against such an API on the basis that, if
> you pass a context, you want to ensure that the message was created in
> that context - but that will only be possible once we can reject
> v1 SEIPD and v4 signature packets, which might take a while, of course.)
> 
>> i know we don't have a common API for OpenPGP other than SOP [1], but
>> what would an API that includes these contexts actually look like? how
>> would it behave? If you have a preferred API to consider, how would you
>> imagine extending it to support these contexts?
> 
> In OpenPGP.js, I would tend to add a top-level "context" parameter to
> the sign, verify, encrypt and decrypt functions.

+1

>> Are we talking about a new argument for packet generation (when
>> generating signatures and SEIPD), which would be ignored if the version
>> of the generated object doesn't support it? or would it be an error if
>> a caller asks for a context for an object that can't use the right
>> version? What about packet consumption? If i get a signature
>> verification based on my provided context, does that mean that the
>> context was really used? What about if i'm decrypting a message?
> 
> Yeah, these are good questions; I think it would be nice to guarantee
> that, but that might be impossible in a non-greenfield implementation.
> Whether a message is produced / accepted without a context, if a context
> parameter was passed, could depend on a configuration option, that starts
> out as true, but (once v2 SEIPD and v5 signatures are widely supported)
> could be flipped to false, at least for production, and later for consumption.

> 
> Regarding the summarizing questions: since this is an application-
> specific mechanism, I think they should be considered (and solved) in an
> application-specific way. This proposal merely provides a mechanism in
> OpenPGP, it doesn't address how to deploy it. As mentioned, [1] provides
> a proposal for email, but OpenPGP claims to be a general protocol,
> suitable for any application.
> 
> And that I think also points to why this mechanism is especially needed:
> if we don't provide a context parameter, applications obviously won't
> use it, and if two applications are used with the same OpenPGP keys, it
> can cause vulnerabilities. So in my view, we should provide a mechanism
> to address that, and (from the perspective of OpenPGP) encourage
> applications to use it, and separately (for each application) discuss
> how best to use it.

I want to emphasize this, and add a concern that I also included in the ALPACA paper for TLS: The problem of context separation in general is an issue that becomes more urgent the more widely a solution is adopted. This group wants OpenPGP to be a widely used format that is used in many different applications and protocols. The more this is true, the more risk for context confusion attacks exists. The number of combinations grows quadratically with the number of protocols and implementations. But it is easy to reduce this to a more manageable size, where confusion can only happen within one protocol or context.

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