Re: [openpgp] Encryption and signature context parameter

[Marcus Brinkmann <[e-mail]>]

Hi,

Thank you for the continuing thoughtful consideration! I will reply to all of your major points below.

> Am 14.10.2022 um 06:20 schrieb 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.

Well, I am not here to tell anybody, especially those with actual responsibility for implementations, what to do. I am mainly here to share what we found out in our research, and to suggest possible consequences of any particular proposal that is being discussed to the best of my ability, as well as to learn what lead to the eventual decisions when they have been made.

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

[...]

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

From a purely cryptographic point of view, forcing the receiver to reconstruct the context from the actual context is correct.

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

I would disagree, and to clarify why I want to define more precisely the words „message“ and „context“ for this use case.

The „message“ for me is not the email, but the (encrypted) OpenPGP message (i.e., the body of a single MIME part). This is what is protected cryptographically. It is also what is typically passed to the OpenPGP library from the application. Everything else is part of the email, but not part of the message.

For the word „context“, I would first like to stipulate an ideal world, and then size it down to realistic expectations. Ideally, the context would be what the email client shows to the user in addition to the deciphered message, and also what influences the behavior of the email clients with regard to the affordances of the message, such as what happens when the user presses the „Reply“ button. This is usually extracted by the email client from the email headers and MIME structure, but it’s not the same. Of course, what email clients show is not well-defined, so we can not really use it to derive a stable context that can be anticipated by the sender. So the compromise here is that the sender tries to anticipate the header fields and parts of the MIME structure that are relevant to the context of the recipient’s email client, and then calculates the context based on that. But we made a considerable effort in the paper to bring the ideal world and the compromise in alignment, for example by evaluating which header fields are used by email clients when the „Reply“ button is used.

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

Yes. For the paper we simplified it a bit, but just using straight DKIM policies would also work (in fact, earlier versions of our paper did use the DKIM policies with the n+1 repetitions rule).

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

Well, that doesn’t work, because if the cipher text is identical then any observer who can see both cipher texts will trivially know that they are the same message. For example, both mail servers could be colluding, or they could be one and the same. It’s certainly not one of the standard security notions that cryptographers use, and it seems very narrow to me.

A better way to achieve this is to simply encrypt the same message twice, once for Bob, and once for Carol. What could be sad about that?

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

It’s difficult to analyze an incomplete proposal, but this seems to be inspired by Signal, so I will just assume for the sake of discussionthat one wants to speak a signal variant (let’s say „CoolBlobs“) over email. Sure, one can do that. But then one should just discard everything that is not the opaque blob, and use a context string like „cool-blobs“ for this protocol.

Let’s look at Signal a bit closer. Signal derives the (symmetric!) encryption keys from the (signing, asymmetric) identity keys using a contextualized HKDF (according to https://signal.org/blog/sealed-sender/ <https://signal.org/blog/sealed-sender/>):
e_chain, e_cipherKey, e_macKey = HKDF(salt="UnidentifiedDelivery" || recipientIdentityPublic || e_pub, ikm=ECDH(recipientIdentityPublic, e_priv), info="")
And of course, instead of contextualization the encryption of text messages Signal has very strongly separation through the DH key exchanges and the double ratchet (which is much more fine-grained than our email proposal).

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

Well, if the WG wants to say something about context strings, it should probably define some namespace mechanism and allow context-dependent additional information for fine-grained separation. That gives the most flexibility to application developers.

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

I would disagree with the characterization of these two attack classes as „two bugs“. We found multiple implementation bugs in each category.

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

For REPLY, the attacker also modifies the header, but yeah, that’s basically it. But I am not sure why you say this is a misbehavior. It’s exactly what the MIME and PGP/MIME standards require of MUAs.

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

This was our initial approach in mitigation. It did not achieve the desired result. We could find bypasses even after several iterations, and some of these measures broke the decryption of legacy emails or interoperability with other email providers (please see Section 2.4. in our Schwenk2020). This is why we were looking for an alternative approach.

I also don’t agree that the decryption context is „complicated“ or „tricky“. It is objectively much simpler than DKIM, MIME, PGP, or any other part of a MUA. My prototype implementation was an additional 204 lines of code to Enigmail, and I had to modify 15 existing lines. But more importantly, our proposal prevents implementation errors by a cryptographic barrier, and defaults to a more secure behavior when some things go wrong. Given our experience with the difficulties of implementers to control the MIME processing and rendering, this seems to be desirable to us.

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

We expect it to shift over time, which is why the proposal is extensible.

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

That was not our intention. In our proposal, the policy is sender-enforced. If the sender chooses a weak policy, they prefer compatibility (fewer false positives) over security. We argue that this makes sense, because (before decryption) only the sender knows what the content of the message is and how sensitive it is.

> Put another way,
> what kind of defense are we talking about if a Decryption-Policy header
> just says "date“?

None, the receiver attempts to decrypt with this context and if that succeeds, they show the message.

> 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 policy was good enough for the sender, then that’s good enough for the receiver as well.

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

There needs to be some community agreement about the meaning of some of the email headers, for example with regard to the relevant headers for the „Reply“ button. But that is already the case for functional reasons, and we demonstrated in our paper how this can be evaluated. We also showed that it is already possible to find good policies to prevent reply attacks.

>  What are the implications for how to handle a message that
> was generated with a different policy in the past?

If you do that, you may be in trouble, but that is not worse than the status quo.

As a general note, and I realize that this is broadening the discussion considerable, I think it is not cryptographically sound to store encrypted data indefinitely without having a process to reencrypt it from time to time with new keys. I would suggest that MUAs should not leave the original emails untouched in IMAP folders, but replace them with reencrypted copies, which are updated from time to time.

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

In my mind, there is a preference to signaling outside of OpenPGP. There are two basic cases:

* New use cases can define the context from the start and do not need elaborate mechanisms for negotiation, etc.

* Legacy applications will need some strategy to negotiate the transition to using a context, but as they are already interacting, there will usually be some application-defined way outside of OpenPGP to negotiate that.

In either case, I don’t really see how the OpenPGP standard can add value by being opinionated on these issues.

What would be helpful though is some kind of registry or namespace hierarchy to avoid accidental overlap.

Thanks,
Marcus

> 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.
> _______________________________________________
> openpgp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/openpgp


—
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