Subject: More mail madness?

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 14 May 2018 11:52:58 -0400

This is a security issue certainly, but it is a particular type of issue
that arises from attempting to analyze the security of a large and complex
system built from parts whose interactions as so complicated that they are
never likely to be sufficiently understood.

https://efail.de/

Basically the attack is to create a new multipart MIME message and sandwich
the ciphertexts we wish to break between chunks of HTML with a URL
reference to a web server we control.

This sort of attack could be devastating in certain situations.

The other attack they describe, the CBC gadget attack is one that I have
already been using a control against. I use a key derivation function to
calculate IVs rather than passing them in-band. I started doing this
because it cleans up the message flows a lot but it also turns out to have
security advantages.

---

From: Russ Housley <[email-masked]>
Date: Mon, 14 May 2018 12:29:01 -0400

We are working on text for S/MIME that says that each portion of a MIME multi-part needs to be handled in its own sandbox.  The direct exfiltration that is described happens because the mail user agent glues the various portions together for display to the user, which in the example on the web page causes an image to be fetched from the attacker's website with the message plaintext as part of the URL.

Russ

> On May 14, 2018, at 11:52 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> This is a security issue certainly, but it is a particular type of issue that arises from attempting to analyze the security of a large and complex system built from parts whose interactions as so complicated that they are never likely to be sufficiently understood.
> 
> https://efail.de/ <https://efail.de/>
> 
> Basically the attack is to create a new multipart MIME message and sandwich the ciphertexts we wish to break between chunks of HTML with a URL reference to a web server we control.
> 
> The other attack they describe, the CBC gadget attack is one that I have already been using a control against. I use a key derivation function to calculate IVs rather than passing them in-band. I started doing this because it cleans up the message flows a lot but it also turns out to have security advantages.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 14 May 2018 12:35:06 -0400

> On May 14, 2018, at 12:29, Russ Housley <[email-masked]> wrote:
> 

So that’s the bandaid. What and where will work be done on a solution?

Paul

---

From: Russ Housley <[email-masked]>
Date: Mon, 14 May 2018 12:37:28 -0400

> On May 14, 2018, at 12:35 PM, Paul Wouters <[email-masked]> wrote:
> 

LAMPS just sent an update to the S/MIME message document to the IESG.  My guess is that there will be discussion on the [email-masked] <mailto:[email-masked]> mail list.

Russ

---

From: Richard Barnes <[email-masked]>
Date: Mon, 14 May 2018 12:39:27 -0400

Russ: Is there some more work to be done here to address the CBC/CFB
issues?  Even if the encapsulation has AEAD support, maybe there's some
negotiation thingy?

On Mon, May 14, 2018, 12:37 Russ Housley <[email-masked]> wrote:

> We are working on text for S/MIME that says that each portion of a MIME
> multi-part needs to be handled in its own sandbox.  The direct exfiltration
> that is described happens because the mail user agent glues the various
> portions together for display to the user, which in the example on the web
> page causes an image to be fetched from the attacker's website with the
> message plaintext as part of the URL.
>
>
> LAMPS just sent an update to the S/MIME message document to the IESG.  My
> guess is that there will be discussion on the [email-masked] mail list.
>
> Russ
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 14 May 2018 13:02:32 -0400

> So that’s the bandaid. What and where will work be done on a solution?

A CBC-MAC (or some other suitable ciphertext MAC) would probably help to
defeat tampering with the CBC ciphertext.  As would encrypt-then-sign
(rather than the more typical for S/MIME sign-then-encrypt), but S/MIME
signatures are optional, so a ciphertext MAC seems appropriate.

-- 
	Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 14 May 2018 13:03:56 -0400

Here is the approach I use for encryption which guards against the IV
attack. It might seem a little over the top but the objective here is to
minimize the number of code paths rather than the length of the code path.

The reason I started on this approach was I was looking for a secure way to
encrypt chat room logs etc. without having to do a key exchange per
message. In the process, I realized that the same approach works remarkably
well in S/MIME like applications where we may have multiple multiparts that
we want to encrypt under one key exchange, we may want to encrypt subject
lines and we may want to encrypt signatures over the plaintext.

1) Generate fresh session key of at least 256 bits which has the property
of being infeasible to guess (note that unguessability is a stronger
requirement than merely being random).

2) Perform a key exchange for each recipient.

2a) If it is a DH or EDH key exchange, use the key exchange result as the
IKM for a KeyDerivation function with info tag "master". Then use the
resulting key to perform an AES Key Wrap of the session key.

3) Create the Enhanced Data Sequences.

For each EDC we create a salt value which needs to be unique within the
context of this particular exchange.

We then use HKDF to derive the encryption (+MAC if needed) and IV.

This approach ensures that the IV is chosen in a rigid fashion and thus
eliminates a possible area of manipulation as any change to the salt will
prevent decryption and authentication of the message as well.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 14 May 2018 13:17:12 -0400

>>>>> "Viktor" == Viktor Dukhovni <[email-masked]> writes:

    >> So that’s the bandaid. What and where will work be done on a

    Viktor> A CBC-MAC (or some other suitable ciphertext MAC) would
    Viktor> probably help to defeat tampering with the CBC ciphertext.
    Viktor> As would encrypt-then-sign (rather than the more typical for
    Viktor> S/MIME sign-then-encrypt), but S/MIME signatures are
    Viktor> optional, so a ciphertext MAC seems appropriate.

More generally, I'd strongly suggest that even for confidentiality
without security, you want the security property of semantic security,
and you want some non-malleability property.

My point is that S/MIME seems to want some properties of its underlying
bulk encryption service that CBC clearly doesn't provide.
I think that in addition to recommending new ciphers, it's worth clearly
articulating what security properties you need.  Doing so helps make
analysis of the system easier.  I've found that doing similar work has
saved me from some attacks like this in my own work both inside and
outside the IETF.
It's possible that some or all of this has already been done: it's been
a while since I've read the S/MIME specs.

---

From: Russ Housley <[email-masked]>
Date: Mon, 14 May 2018 13:42:05 -0400

> On May 14, 2018, at 1:02 PM, Viktor Dukhovni <[email-masked]> wrote:
> 
> 
> 

https://www.ietf.org/id/draft-ietf-lamps-rfc5751-bis-08.txt <https://www.ietf.org/id/draft-ietf-lamps-rfc5751-bis-08.txt>

This document has already been sent to the IESG.  It says:
Sending and receiving agents:

   -  MUST support encryption and decryption with AES-128 GCM and
      AES-256 GCM [RFC5084].
Russ