Re: Message takeover attacks against S/MIME
Sean Turner <[email protected]> Mon, 1 Feb 2016 18:02:38 -0500
| Newsgroups | gmane.ietf.smime |
|---|---|
| Message-ID | <[email protected]> |
I’m willing to help too, but it would be really great if we could identity some folks who work on [insert your favorite mail app with built-in S/MIME support] to also be involved. spt > On Jan 28, 2016, at 11:38, Jim Schaad <[email protected]> wrote: > > 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 protected]] On Behalf Of Russ Housley >> Sent: Thursday, January 28, 2016 7:47 AM >> To: IETF SMIME <[email protected]> >> 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. >> >> 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 >> >> _______________________________________________ >> smime mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/smime > > _______________________________________________ > smime mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/smime _______________________________________________ smime mailing list [email protected] https://www.ietf.org/mailman/listinfo/smime