Subject: [smime] Message takeover attacks against S/MIME

From: Russ Housley <[email-masked]>
Date: Wed, 27 Jan 2016 17:39:41 -0500

Take a look at this article: http://cryptosource.de/posts/smime_mta_en.html

Is there interest in updating the S/MIME specification to use authenticated-encryption?

Russ

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 Jan 2016 18:50:50 -0500

> Is there interest in updating the S/MIME specification to use authenticated-encryption?

Is the attack limited to S/MIME or does it affect OpenPGP as well?

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 28 Jan 2016 15:02:37 +0000

If I'm reading this right, the attack converts a signed-then-encrypted message into encrypted-then-signed by exploiting the use of CBC mode.  The attacker deletes, moves, or alters encrypted message blocks (excepting blocks with pad bits) such that most of the message still decrypts into readable text but the inner signature breaks.  Then he applies his own outer signature.  

Because the S/MIME spec requires clients to accept both types of messages and parsing of structures is lax, the recipient will accept the altered message.  If the recipient replies, he often will include the original message content as a quoted section, and confidentiality is lost.

OpenPGP forbids encrypt-then-sign (no format for it), so it's not vulnerable.

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 28 Jan 2016 15:04:33 +0000

> Is there interest in updating the S/MIME specification to use authenticated-

Seems like it would be a straightforward update.

-- T

---

From: Lijun Liao <[email-masked]>
Date: Thu, 28 Jan 2016 11:02:51 +0100

Indeed there are much simple ways to get the encrypted messages by adding
some header fields like Reply-To, Sender, To, CC, etc. Since these header
fields are not cryptographically protected by the signature and encryption,
the recipient mail client is not able to detect the modification. If she
answers the email, a copy will be delivered to the attacker.

Sure the aforementioned attack can be HINDERED by the inline message type
message/rfc822 introducted in S/MIME v3.1. I use here the word HINDER
instead of PREVENT due to the fact that the specification does not prevent
the recipient client from using the outer header fields which are not
protected. By the way, not all of email clients (indeed I know none) can be
configured to accept only intern message/rfc822 type.

Lijun Liao

---

From: Russ Housley <[email-masked]>
Date: Thu, 28 Jan 2016 10:47:21 -0500

I do not know of any user agents that can be configured to accept only intern message/rfc822 type, or even flag the difference to the user.  Most users would not understand the flag if it was there.

I would like to know if there is enough energy to work on a re-charter for the SMIME working group and then produce an updated specification.  If there is enough interest, Stephen Farrell is willing to sponsor the charter.

I am willing to work on it.

Russ

On Jan 28, 2016, at 5:02 AM, Lijun Liao wrote:

> Indeed there are much simple ways to get the encrypted messages by adding some header fields like Reply-To, Sender, To, CC, etc. Since these header fields are not cryptographically protected by the signature and encryption, the recipient mail client is not able to detect the modification. If she answers the email, a copy will be delivered to the attacker.
> 
> Sure the aforementioned attack can be HINDERED by the inline message type message/rfc822 introducted in S/MIME v3.1. I use here the word HINDER instead of PREVENT due to the fact that the specification does not prevent the recipient client from using the outer header fields which are not protected. By the way, not all of email clients (indeed I know none) can be configured to accept only intern message/rfc822 type.
> 
> Lijun Liao

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 28 Jan 2016 08:38:28 -0800

I am more than willing to help with this.  I don't know if there will be any
industry pickup but I think it does need to be done.

Jim

> -----Original Message-----
> From: smime [mailto:[email-masked]] On Behalf Of Russ Housley
> Sent: Thursday, January 28, 2016 7:47 AM
> To: IETF SMIME <[email-masked]>
> Subject: Re: [smime] Message takeover attacks against S/MIME
> 
> I do not know of any user agents that can be configured to accept only
intern
> message/rfc822 type, or even flag the difference to the user.  Most users
would
> not understand the flag if it was there.
> 
> I would like to know if there is enough energy to work on a re-charter for
the
> SMIME working group and then produce an updated specification.  If there
is
> enough interest, Stephen Farrell is willing to sponsor the charter.
> 
fields
> are not cryptographically protected by the signature and encryption, the
> recipient mail client is not able to detect the modification. If she
answers the
> email, a copy will be delivered to the attacker.
> >
the
> recipient client from using the outer header fields which are not
protected. By
> the way, not all of email clients (indeed I know none) can be configured
to
> accept only intern message/rfc822 type.
> >
> > Lijun Liao
> 
> _______________________________________________
> smime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/smime

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 29 Jan 2016 04:37:15 +0000

>Is there interest in updating the S/MIME specification to use authenticated-

It looks like a pretty contrived attack, you need to be able to truncate a
message, both at the start and end, on a 16-byte boundary to turn a signed
message into a plain, unsigned one, and still have the client accept the
result as a valid message.  They found one client that does that, but that
sounds more like a buggy client than a major problem (none of the others did
it).

In any case the fix should be pretty minimal, if anything is required at all:
If the SMIMECaps in the cert you're encrypting for indicates authEnc, use
that.  My code already does that and possibly other impementations do too.

Peter.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 29 Jan 2016 14:46:51 +0000 (UTC)

If the only thing we need to do is add AES-GCM, then the obvious venue is CURDLE. 
But we do need to do something soon because S/MIME is loosing deployment support. It isn't in the new Microsoft platform mail system, it is virtually unusable in iOS, it is absent in the Android client and it takes 30 minutes to configure Thuinderbird. That would not worry me if OpenPGP was filling the gap but it is not.
If we are going to get working end to end secure mail, several things have to happen:
1) Stop the S/MIME vs OpenPGP standards battle. The GNU code and most of the other libraries for OpenPGP support S/MIME. They have to do PKIX for SMTP STARTLS, S/MIME is a minor extra burden.
The choice of message infrastructure should not determine the choice of the trust infrastructure. It is not possible to solve every trust problem with either PKIX or Web of Trust or direct trust via fingerprints.
2) We have to have up to date specifications for the end-to-end message formats that define a consistent modern crypto suite. [CURDLE]
3) We have to work out how to make end to end mail work properly with Web Mail 
4) Configuration of the clients has to be absolutely painless. Which is what I designed the Mathematical Mesh to address. Use cryptography to solve the problem of making computers easier to use.
I am just redoing my podcast demonstrating the Mesh, the sound on the first one doesn't meet my standards.

If people want to look at what I have done and then do the same thing completely differently, that is fine with me as long as they do it, deploy it and it works as well. But given that I am using a completely modern, fashionable set of standards (HTTP/1.1, JSON, JOSE, CURDLE) and none of this requires a CA, I can't see it likely people would want to make that sort of change.
It does need review though. And deployment. The killer app for the Mesh can't be secure email because there isn't much value to a system that reaches 0.1% of Internet users (combined user as of OpenPGP and S/MIME). But most people would like to have an easy, robust and really secure way to manage SSH keys, most people would like an easy way to encrypt their data in the cloud and pretty much everyone is fed up with having to remember passwords for 100 web sites. All those benefits are immediate regardless of whether anyone else buys in.
The Mesh itself is an untrustworthy service, this is a completely end to end protocol. The user is in direct and full control of all their data at all times.

Sent from Outlook Mobile

    _____________________________
From: Peter Gutmann <[email-masked]>
Sent: Thursday, January 28, 2016 11:37 PM
Subject: Re: [smime] Message takeover attacks against S/MIME
To: Russ Housley <[email-masked]>, IETF SMIME <[email-masked]>

Peter.

---

From: Russ Housley <[email-masked]>
Date: Fri, 29 Jan 2016 11:23:24 -0500

> that.  My code already does that and possibly other impementations do too.

CMS already supports Enveloped-Data and Authenticated-Enveloped-Data.  However, the S/MIME specification does not say how to use Authenticated-Enveloped-Data.  I think that is the work to be done.

Russ