Re: [openpgp] Encryption and signature context parameter

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

Hi Marcus, Daniel, and the rest of the WG--

Thanks a lot for this discussion.  Clearly there are compelling
arguments for trying to fix the various pieces of E-FAIL, and this
proposal might well be on the path to doing so.

I'm just not sure that they should be on the path to releasing the
revision to RFC 4880.  I've been chewing this over for a day now, and
i'm afraid this message is very long.

This message is written with no formal IETF or WG Chair hat on -- just
as an implementer, someone who thinks about ecosystem evolution, and who
cares about getting this stuff out in the world in ways that more people
can actually use sooner rather than later.

On Wed 2022-10-12 15:31:57 +0200, Marcus Brinkmann wrote:
> 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.

Thanks for this clarification -- i understand what you're saying here,
and i think maybe it makes the most sense to focus on contexts for
encryption in this discussion.

If the WG can be convinced that it is useful for encryption, then it's
probably not too hard to convince the WG about its knock-on utility for
signatures.  But if the mechanism isn't compelling enough to use for
encryption, it sounds like there are other ways to achieve similar goals
for signatures without the context.

> [dkg wrote:]
>>> 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.
>>
>> [daniel huigens wrote:]
>> Yes, I agree.
>
> +1

I think what i'm hearing is that even the advocates for this mechanism
agree if the the context has to travel with the message, this might not
be worthwhile based on the additional complexity costs and
interoperability risks.  Is that right?

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

This proposed "fine-grained e-mail context separation" appears to depend
on at least part of the context travelling with the message, right? 

The message's outer headers (what the paper calls "SMTP Headers", though
they're nothing to do with SMTP) are being munged into the context,
using the DKIM "relaxed" header canonicalization scheme.  (if you're
going to include the headers in the context, re-using the DKIM
canonicalization scheme is absolutely the right choice, btw, both
because of already-available libraries, and because fiddling that breaks
DKIM canonicalization will be more likely to be noticed and corrected
for other reasons)

One thing that makes me sad about this scheme is that it puts more
weight on keeping outer headers visible and fixed across different
copies of the message.  For example, if Alice wants to send a mail to
Bob and Carol, and she's using header protection, and doesn't want Bob
or Carol's mail servers to know that the message was delivered to the
other one, Alice can no longer encrypt the message once, and then put
different headers on the outside of the copy she sends to Bob than she
puts on the outside when she sends to Carol.

The not-so-secret longterm goal for header protection is to be able to
send basically opaque blobs via SMTP, possibly allowing for some sort of
"sealed sender" or platform-delegated blocklisting [0] for spam
abatement.  We're nowhere near that in the ecosystem, of course, but if
deployment of this kind of context makes it even harder to get there,
that would mean locking e-mail into permanent metadata leakage. That
seems like a bad path to go down.

[0] https://www.usenix.org/conference/usenixsecurity22/presentation/tyagi

How would this fine-grained decryption context scheme work in a world
where the only meaningful header on the outside of some messages is a
"message delivery" token to make it past the transport agent's antispam?
(let's assume that the Decryption-Context: header is also present).
Does it still offer the same level of defense?

> Even just using something like „email“ can prevent some attacks across
> protocols.

Right, so we have one basic question about the application of this
scheme to e-mail: simple standard context, or fine-grained context?

> we are already exposing the plaintext to the risk of direct
> exfiltration attacks in the presence of implementation bugs.

Zooming out a bit, the two bugs that this scheme tries to address are
clearly summarized in the SHCWENK2020 paper as EFAIL-DE ("direct
exfiltration") and REPLY.

It seems to me that both of these two problems come from very specific
misbehaviors of MUAs (the "implementation bugs" that you mention above).

EFAIL-DE comes from MUA's attempts, during message rendering, to stitch
together multiple pieces of content, some of which might be encrypted,
and others of which might not be (or might be an entirely different
encrypted object).  An MUA that refuses to do that, and instead only
decrypts during rendering at a strict MIME boundary is immune to
EFAIL-DE.

And REPLY comes from the MUA's attempts to decrypt *anything* within a
message -- not just the top-level MIME object of the message itself --
during composition of a reply.

Right?

If we can convince a MUA implementer to calculate a complicated
fine-grained context during each attempt at decryption, knowing that
this scheme is likely to result in more unreadable mail or failed
decryption, then it seems much simpler to convince a MUA implementer to
*not* decrypt in the risky cases.

The rules go like this:

 - During message rendering, if you encounter an encrypted object that
   is not encapsulated at a MIME boundary, either DO NOT decrypt, or
   synthesize the appropriate MIME boundaries around the part and render
   the part in this synthetically isolated MIME part.

 - During composition of a reply message, only decrypt the top-level
   MIME part of the message.  Do not decrypt anything else.

If those two simple rules successfully defend against the remaining
categories of EFAIL, it seems much more plausible to ask a MUA to make
these changes, rather than to ask them to generate tricky contexts that
might make decryption even more fragile.

Keep it simple.

Even worse, i think there is a risk that the community's understanding
of what the "strong" SMTP and MIME policies (§7.2 of the paper) could
shift over time.  My understanding of the approach here is that the MUA
should evaluate the message's "Decryption-Context" header to determine
*whether* it meets the receiving MUA's expectations of what a strong
policy looks like before deciding to allow decryption.  Put another way,
what kind of defense are we talking about if a Decryption-Policy header
just says "date"?  We know that's not a strong policy; what should the
receiving MUA do if it sees a message without a strong policy?  if the
answer is "do not decrypt" because the policy is too week, then what
happens if the community understanding of strong policy shifts over
time?  How do different MUAs communicate their policy expectations to
each other?  What are the implications for how to handle a message that
was generated with a different policy in the past?

I think all of the above are arguments in favor of either not using a
context, or -- if we do use a context -- using a simple, static string.

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

I'm sympathetic to this argument, and i *definitely* don't want the
OpenPGP WG to have a big argument about "what is the appropriate context
string for e-mail decryption" before we produce the next revision of RFC
4880.  This already makes me leery about tossing this into the spec at
the last minute.

But i *do* think that introducing this feature without any plausible
scheme for deployment in the most common/obvious context (e-mail) is
potentially dangerous for interoperability.

For example:

 - Let's imagine there is a consensus about what the context should
   be. (so i'm setting aside the whole complicated question here, and
   just positing that we have a clear answer)

 - Alice wants to send an encrypted message to Bob and to Carol.  For
   this particular message, if it were to use a decryption context, it
   would be $CONTEXT. (maybe that's the scheme described in the paper,
   using a sensibly-constructed Decryption-Context header, maybe it's
   just the literal string "email")

 - Does Alice use $CONTEXT during encryption, or does she not use it?
   How does her MUA decide (let's assume that we don't burden the user
   with making this decision)?

One approach ("version-bound") would be to say "MUST NOT encrypt e-mail
messages using v2 SEIPD without calculating the known context".  That
is, gating the use of v2 SEIPD to complete and inerrant knowledge of the
context.  If Alice knows that Bob and Carol can use v2 SEIPD, she'll
include the context, and out it goes.

Another approach ("signalling") would be for Bob and Carol to separately
advertise (in their OpenPGP certificates?  some other way?) their MUAs'
knowledge of the appropriate decryption contexts to use in e-mail.

The version-bound approach seems likely to delay adoption of v2 SEIPD
even further in the e-mail context.  We would need to bake that strict
directive into the revised RFC -- even if we don't know what the correct
context is yet -- and then we'd need to guide MUAs into being strict
here.  Outside of the e-mail context, it's even hairier :/

The signalling approach has its own caveats and gotchas.  How do Bob and
Carol know what signal to emit?  What if they use two different MUAs
each, and some MUAs know about the context and others don't?  I don't
think we want the user to have to configure this manually, but we also
don't want one of Bob's MUAs to encourage senders to emit encrypted
messages that Bob's other MUAs will fail to decrypt.

Even if Bob and Carol are confident in accurately reflecting their
MUA(s) capabilities in whatever the signal is, what if Bob's
advertisement says he can handle (and prefers) decryption contexts, and
Carol's advertisement says she cannot?  Presumably, Alice encrypts the
message *without* a decryption context, even though she might encrypt
individual messages to Bob *with* the decryption context.

Also, if we're going to use a distinct signalling mechanism, then it
smells like the moral equivalent to a v3 SEIPD, but focused on the
particular domain in question, which means it *doesn't* need to be
defined now.

For example, a future specification could (a) introduce v3 SEIPD, which
is identical to v2 SEIPD plus the context parameter, but indicating that
it MUST NOT be used in any domain without well-defined, signalled
support, (b) define exactly how it is used in the domain of e-mail
messages (maybe even declaring a fixed policy), and (c) claim one of the
bits in the feature packet to mean "I can do v3 SEIPD in the domain of
e-mail messages, using this exact policy".

That still doesn't solve the problem of getting Bob's MUAs to all agree
that it's OK to set that bit in his cert, but it is at least a clear
deployment strategy that won't block us from getting real-world
practical experience with v2 SEIPD.

And it doesn't need us to change anything in the crypto-refresh draft,
to get the proximate revision to RFC 4880 out the door.

   --dkg

PS i would be seriously happy to include work on something like the "v3
   SEIPD + e-mail message policy for decryption context + signalling"
   spec i sketched above as an item in a potential WG recharter if folks
   are interested.