I'm sorry I'm late to this conversation, but I also wanted to volunteer to
help update the S/MIME specification. Authenticated encryption would be
very helpful in mitigating the attacks mentioned in the posted article.
One additional suggestion is considering recent standardized crypto in
RFC7539 for S/MIME. ChaCha20-Poly1305 provides more crypto algorithm
diversity, and is potentially faster than AES based authenticated
encryption (e.g. on mobile) . It may have other useful properties for
S/MIME as well.
-Wei
On Fri, Jan 29, 2016 at 8:23 AM, Russ Housley <housley(_at_)vigilsec(_dot_)com>
wrote:
Peter:
Russ Housley <housley at vigilsec.com> writes:
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?
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.
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
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime