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
<michael(_at_)stroeder(_dot_)com>
wrote:
Paul Hoffman wrote:
On Jan 3, 2015, at 4:32 AM, Michael Ströder
<michael(_at_)stroeder(_dot_)com>
wrote:
Isn't it the time to deprecate using tripleDES and add a stronger
SHOULD for
using stronger symmetric ciphers?
Why? I have not seen any attacks on TripleDES that make it insecure.
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.
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.
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime