Re: Message takeover attacks against S/MIME

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
<https://tools.ietf.org/html/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 <https://tools.ietf.org/html/rfc4134> (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