Re: Message takeover attacks against S/MIME

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 <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/smime