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