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

[Daniel Kahn Gillmor <[e-mail]>]

I've been puzzling over this question about encryption and signature
context parameters, while looking at Daniel's notes in the issue tracker
and proposed merge request:

https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/145
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/214

I'm sympathetic to the idea of these context strings, but i'm also
pretty wary about adding mechanism that i don't think we understand.

The notes in this message are in my personal capacity, not as co-chair.
If someone on this list feels they have solid answers to the questions
i'm raising here, i could maybe be convinced.  but i'm leaning toward
thinking this change is not worth doing to the spec.  We have other ways
to accomplish some similar (but not quite as protective) things that
would be less disruptive than this change.

I have five main lines of questioning here:

- both encryption and signatures?
- should the context travel with the OpenPGP object?
- how should an application select the context?
- what would deployment actually look like?
- what would an API look like for this?

# Both Encryption and Signatures?

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?

For example: for signatures, there can be an attack on the signer
(making them try to sign something in a strange context) or an attack on
the verifier (trying to make them accept a signature with the wrong
context).  iiuc, an example attack on a signature might be trying to
make an e-mail message be evaluated as a software signature, or vice
versa.

And for encryption, there is an attack on the encryptor (making them
encrypt something in an unusual context), and an attack on the decryptor
(making them decrypt something somewhere where they shouldn't be).  An
example attack might be sending someone one of their encrypted backup
files as an e-mail message and hoping that they will reply to it,
effectively including the contents of the backup in the encrypted reply.

These are subtly different things, and i think i'm convinced that
they're both things that *could* be mitigated if every OpenPGP
deployment was judicious about the choice of context string, but i'd
welcome other thoughts.

# Should the context travel with the OpenPGP material?

As Marcus says, having the context travel literally and explicitly with
the packet offers the enticement for consuming implementers to
"cheat" -- and just pass the context string discovered with the object
without confirming that it is actually the right context.

Of course, right now, *no* implementation confirms that it is the right
context (because there is no such context mechanism) so this isn't worse
than the status quo.  But is it any better than the status quo to have
the context shipped with the OpenPGP material?

- for signing, it appears that it's still useful because the signer is
  obliged to choose a context for her signature, probably not under the
  influence of the attacker.  However, as long as the attacker can get
  the signer to sign arbitrary content in a specific *situation* where
  the desired bad context is used, there is still an attack possible.
  Or, if the attacker is capable of asking the signer for a signature
  over arbitrary content, who is to say that the attacker couldn't also
  ask the signer to provide an explicit context string as well?

  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.  The only difference here is that the context string is
  *before* the message being signed, but a notation shows up *after* the
  message being signed.

  So shipping the context with the signature feels like a lot of new
  mechanism that could be accomplished in a way that's already defined,
  and doesn't provide much of a win.

- for encryption, it might appear to be useful because the decryptor can
  say "i'm only going to decrypt things that have context X" and refuse
  to decrypt if the context doesn't match.  But we already know that
  it's very hard to convince an implementation to *not* decrypt for the
  user when it might be able to figure out how to decrypt (e.g. see all
  the discussion and heartache around decrypting the known-bad SED
  packets).  Having a required context string for successful decryption
  is an expansion of the opportunities for an OpenPGP object to be
  un-decryptable, which is a very frustrating failure mode for the user.
  So if the context is shipped with the object, the temptation to cheat
  is *very* great.

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.

# How should an application select the context?

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

[0] https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/

But how are implementers supposed to know what to choose?  do we need a
registry?  Do we need guidance?  does "software package" make sense?  or
should it be "tarball" or ".deb" or ".rpm"?  What about "Debian"
vs. "Ubuntu"? Should acceptable encryption context strings be advertised
in the OpenPGP certificate of the recipient?

These are a ton of open questions that this mechanism brings up, and i
don't know how to resolve them.

# What would deployment look like?

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?

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?

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?

If we take this latter route, then some of the gains *only* come when at
least some of the parties involved have fully stopped producing or
consuming the older formats.  And, it appears to raise the bar for
adopting the newer formats in contexts where the older formats are
already deployed.  It's not just a matter of upgrading the cryptographic
stack, but now the deployment needs to know its expected context.

# What would the API look like for this?

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?  

[1] https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/

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?


------

In summary, i think this mechanism is intriguing, and i see the real
concerns it is trying to address.  But i'm not convinced this is the
right (or plausible) thing to do logistically.

I also think we have some mechanisms that can approximate some of the
advantages already (signature subpackets, notations) for implementations
that want to be a bit stricter (equivalent of having the context travel
with the objects).  And i think taking it all the way (where it doesn't
travel with the object) raises a whole bunch of questions, like:

 - how does an application knows what its necessary context is?

 - how the ecosystem coordinate and scope the domains that the mechanism
   intends to separate?  What if one MUA thinks that the appropriate
   scope for encryption is the mail-addr of the primary inbox address,
   but another MUA thinks it should just be the literal "e-mail
   encryption".  Who gets to decide?  How will they interoperate?

 - how can we avoid this additional wrinkle becoming an obstacle to
   deployment in places where we want to roll out the new versions?  If
   there's an OpenPGP library, what else does the application have to do
   when initializing the library, rather than just upgrading to the new
   version?

 - if we can't answer these questions, how do we avoid this becoming yet
   another way that OpenPGP implementations might fail to interoperate?
   There are a lot of moving parts in OpenPGP, many of which are simply
   not implemented, but seemed like good ideas at the time.  How do we
   keep this from being one of those?

So I'm pessimistic about this, but I'm willing to be convinced
otherwise.

Regards,

   --dkg