Re: [smime] Message takeover attacks against S/MIME

Erik:

CMS already has a content type that supports AEAD algorithms.  There will 
probably need to be some documents that specify the conventions for using new 
AEAD algorithms, but I do not anticipate any changes to CMS itself.

Russ


On Mar 29, 2016, at 4:25 AM, Erik Andersen <era(_at_)x500(_dot_)eu> wrote:

Does any of proposed action for S/MIME affect CMS?

Erik

-----Oprindelig meddelelse-----
Fra: smime [mailto:smime-bounces(_at_)ietf(_dot_)org] På vegne af Jim Schaad
Sendt: 28 March 2016 18:49
Til: 'Sean Turner' <sean(_at_)sn3rd(_dot_)com>; 'Wei Chuang' 
<weihaw(_at_)google(_dot_)com>
Cc: 'IETF SMIME' <smime(_at_)ietf(_dot_)org>
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:smime-bounces(_at_)ietf(_dot_)org] On Behalf Of Sean 
Turner
Sent: Monday, March 28, 2016 6:11 AM
To: Wei Chuang <weihaw(_at_)google(_dot_)com>
Cc: IETF SMIME <smime(_at_)ietf(_dot_)org>
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 <weihaw(_at_)google(_dot_)com> 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 <weihaw(_at_)google(_dot_)com> 
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 <weihaw(_at_)google(_dot_)com>

wrote:



On Mon, Mar 7, 2016 at 10:58 PM, Russ Housley 
<housley(_at_)vigilsec(_dot_)com>

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
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime



_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime


_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime


_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime

_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime


_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime