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

[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.

> 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.

> 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.

> 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

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.

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.

> 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.

> 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.

> 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.

Best,
Daniel


P.S. I'm supposed to be on vacation starting today (until end of next
week), so I might be slow to respond further, apologies in advance.