Subject: [smime] deprecate tripleDES?

From: Michael Ströder <[email-masked]>
Date: Sat, 03 Jan 2015 13:32:34 +0100

HI!

Isn't it the time to deprecate using tripleDES and add a stronger SHOULD for
using stronger symmetric ciphers?

The text from https://tools.ietf.org/html/rfc5751#section-2.7.1.2 is pretty
blurry:

   [..] If the sending agent
   chooses not to use AES-128 in this step, it SHOULD use tripleDES.

Ciao, Michael.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 3 Jan 2015 07:27:08 -0800

> using stronger symmetric ciphers?

Why? I have not seen any attacks on TripleDES that make it insecure.

>   chooses not to use AES-128 in this step, it SHOULD use tripleDES.

If there are two or more ways to interpret that sentence, we can clarify it. I don't see more than one, but maybe I'm missing something.

--Paul Hoffman

---

From: Sean Leonard <[email-masked]>
Date: Sat, 03 Jan 2015 11:56:32 -0800

> Why? I have not seen any attacks on TripleDES that make it insecure.
+1. I don't see the point in deprecating. It's necessary for 
interoperability with a lot of implementations anyway.

Sean

---

From: Michael Ströder <[email-masked]>
Date: Sat, 24 Jan 2015 10:03:09 +0100

Paul Hoffman wrote:
> If there are two or more ways to interpret that sentence, we can clarify
> it. I don't see more than one, but maybe I'm missing something.

Lazy implementors can read this section like:
"It's fine to only implement tripleDES and not support anything else forever."

Ciao, Michael.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 24 Jan 2015 12:03:06 -0500

There is a missing element in the S/MIME infrastructure, a mechanism that
tells email senders the policy of the receiver.

This leads to a variety of downgrade attacks of which this is only one
example.

* Sending plaintext messages to a receiver who prefers encrypted because
they can read an encrypted message on all their mail devices.

* Sending encrypted messages with a weaker cipher than the receiver
supports.

Guessing the recipient supports a stronger security policy than they
actually do results in a communication failure. And so developers tend to
be conservative in the policy they apply. So all the email is sent
unencrypted by default and 3DES is the default algorithm.

There are still S/MIME libraries out there that only support 3DES, even
when the library itself has AES.

The way to get round these issues is to distribute security policy
statements. This could be in the certificates or in some other part of the
infrastructure.

This is what I expect RFC 4262 is for but:

1) I don't think there is a capability defined for 'I prefer encrypted
email'

2) Working out the capability for 'I support AES-256' requires unreasonable
effort.

3) I have no knowledge of what email clients currently support this
extension.

I think we really need an S/MIME v4 as a branding exercise so we can level
set and know which clients support a common interoperable and secure
baseline.

I don't think we need to drop backwards compatibility here. But we should
complete the necessary infrastructure to make a client usable and we should
define the interface to TRANS and ACME.

We should also embrace and extend the PGP fingerprint model. It is for many
people the most practical way of doing crypto. Rather than forcing people
to choose between two incompatible security schemes to achieve security, we
should extend one or the other to support all the functionality both
currently provide.

I do not think we should adopt the PGP web of trust in the same way however
because I don't think it works as currently specified but it would work a
lot better than any existing scheme if we combined web of trust and CA
based trust and TRANS log type technology.

On Sat, Jan 24, 2015 at 4:03 AM, Michael Ströder <[email-masked]>
wrote:

> _______________________________________________
> smime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/smime
>
>

---

From: Michael Ströder <[email-masked]>
Date: Sat, 24 Jan 2015 18:14:19 +0100

Phillip Hallam-Baker wrote:
> [..]
> I think we really need an S/MIME v4

(sigh)

No, what we need are better implementations.

> This is what I expect RFC 4262 is for but:

RFC 4262 simply stuffs S/MIME caps into a cert extension. Which has its own
drawbacks though but should be discussed another time.

> 1) I don't think there is a capability defined for 'I prefer encrypted

No need for that, or it's at least another topic.

> 2) Working out the capability for 'I support AES-256' requires unreasonable

Seamonkey and Thunderbird MUAs already send the OID for AES-256 in the S/MIME
caps. But they always use 3DES when sending S/MIME messages.

> when the library itself has AES.

And that's exactly the point:
If I want to convince developers to put effort into their implementation to
actually look at S/MIME caps and choose a better cipher it would be nice to
point at an RFC as a good argument. But the current text does not give any
argument at all to support anything else than 3DES.

=> the wording is bad

Ciao, Michael.