Re: Message takeover attacks against S/MIME

I do not envision the S/MIME work having any dependency on the X.894 document.

Russ


On Mar 31, 2016, at 3:03 PM, Tony Rutkowski <[email protected]> wrote:

> Are we discussing the IETF's CMS or
> the ITU-T's just adopted version as
> X.894?
> --tony
> 
> On 2016-03-29 4:25 AM, Erik Andersen wrote:
>> Does any of proposed action for S/MIME affect CMS?
>> 
>> Erik
>> 
>> -----Oprindelig meddelelse-----
>> Fra: smime [mailto:[email protected]] På vegne af Jim Schaad
>> Sendt: 28 March 2016 18:49
>> Til: 'Sean Turner' <[email protected]>; 'Wei Chuang' <[email protected]>
>> Cc: 'IETF SMIME' <[email protected]>
>> Emne: Re: [smime] Message takeover attacks against S/MIME
>> 
>> I am open to suggestions, but until somebody gives be a better answer I do not know how to do the following:
>> 
>>>> * A better mechanism than sign-encrypt-sign to get both 
>>>> authentication and
>>> confidentiality (or at least a non-strippable way of doing it)
>> Using and AEAD algorithm only solves part of the problem as one can do an encrypt-sign but the outer integrity cannot be validated by a third party.  This is also set to be able for third parties to add the outer signature layer and that has been used in several specifications so it is not clear to me that this is one issue that needs to be fixed.
>> 
>> I do to totally agree that we need to start moving to AEAD algorithms however.
>> 
>> jim
>> 
>>> -----Original Message-----
>>> From: smime [mailto:[email protected]] On Behalf Of Sean Turner
>>> Sent: Monday, March 28, 2016 6:11 AM
>>> To: Wei Chuang <[email protected]>
>>> Cc: IETF SMIME <[email protected]>
>>> Subject: Re: [smime] Message takeover attacks against S/MIME
>>> 
>>> If the patient is on the table, then all of these look like items we’d 
>>> need to address.
>>> 
>>> spt
>>> 
>>>> On Mar 26, 2016, at 09:57, Wei Chuang <[email protected]> wrote:
>>>> 
>>>> Some more work item suggestions (I'm posting on behalf of someone 
>>>> who
>>> wishes to avoid the rough and tumble of discussion on the mailing list 
>>> though reads it):
>>>> * Making ECC an official part of S/MIME, RFC5753 is only informational.
>>>> * Authenticated encryption.
>>>> * A better mechanism than sign-encrypt-sign to get both 
>>>> authentication and
>>> confidentiality (or at least a non-strippable way of doing it)
>>>> * Dropping obsolete ciphers and hashes from the spec: drop SHA-1, MD5, etc.
>>>> * A modernized RFC 4134 (practical examples of S/MIME messages, it 
>>>> could
>>> avoid the fiasco of 3rd party forgetting ASN-1 tags in their messages).
>>>> -Wei
>>>> 
>>>> 
>>>> On Sun, Mar 13, 2016 at 9:38 AM, Wei Chuang <[email protected]> wrote:
>>>> Some interesting usability consideration were raised on the PKIX 
>>>> list by Martin
>>> Rex in the thread "another attempt to canonicalize local parts" that 
>>> could be addressed by a rechartered WG.  He points out problems with
>>>> - Incompletely specified cert chains preventing signature verification i.e.
>>> missing CA certs and no ability to fetch them.  Fully specifying the 
>>> chains would resolve this.
>>>> - Reverifying old "archived" emails on his MUA not possible as the 
>>>> certs have
>>> expired.  Fixing a verification time on delivery or other scheme is desirable.
>>>> -Wei
>>>> 
>>>> On Thu, Mar 10, 2016 at 11:12 AM, Wei Chuang <[email protected]>
>>> wrote:
>>>> 
>>>> On Mon, Mar 7, 2016 at 10:58 PM, Russ Housley <[email protected]>
>>> wrote:
>>>> I am hearing interest in these topics (a combination of things on 
>>>> this list and
>>> side conversations).
>>>> (1) Specify the way to use authenticated encryption in S/MIME.  Note 
>>>> that it is
>>> already done for CMS.
>>>> (2) Specify conventions for AES-CCM, AES-GCM, and ChaCha20 with 
>>>> Poly1305
>>> authenticated encryption algorithms.
>>>> (3) Specify conventions for using Curve25519 and Curve448 for key agreement.
>>>> 
>>>> (4) Specify conventions for using the CFRG chosen curves for 
>>>> elliptic curve
>>> digital signature.
>>>> (5) Specify a way to use PGP public keys in addition to PKIX certificates.
>>>> 
>>>> Anything else?
>>>> 
>>>> While I'm afraid of scope creep as resolving the above would be very 
>>>> useful,
>>> could also mail header integrity and privacy be considered?  Perhaps 
>>> the WG scope be split into near and long term work to help prioritize.  
>>> The above five items be categorize as near term and the mail header 
>>> work considered longer term?
>>>> -Wei
>>>> 
>>>> (PS yes there is RFC7508 which is experimental, and does not keep 
>>>> private the
>>> sender and recipient.  Still it is an improvement...)
>>>> 
>>>> Is this enough to re-charter the S/MIME WG?
>>>> 
>>>> Russ
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> smime mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/smime
>> 
>> _______________________________________________
>> smime mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/smime
> 
> -- 
> ________________________________
> 
> Anthony Michael Rutkowski
> 
> EVP, Industry Standards & Regulatory Affairs
> 
> [email protected]
> 
> +1 703 999 8270
> 
> ________________________________
> 
> Yaana Technologies LLC
> 
> 
> 542 Gibraltar Drive
> 
> Milpitas CA 95035 USA
> 
> <T13-SG17-160314-TD-PLEN-2558!R1!MSW-E.doc>_______________________________________________
> smime mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/smime

_______________________________________________
smime mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/smime