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

From: Wei Chuang <[email-masked]>
Date: Wed, 2 Mar 2016 07:37:37 -0800

I'm sorry I'm late to this conversation, but I also wanted to volunteer to
help update the S/MIME specification.  Authenticated encryption would be
very helpful in mitigating the attacks mentioned in the posted article.

One additional suggestion is considering recent standardized crypto in
RFC7539 for S/MIME.  ChaCha20-Poly1305 provides more crypto algorithm
diversity, and is potentially faster than AES based authenticated
encryption (e.g. on mobile) .  It may have other useful properties for
S/MIME as well.

-Wei

On Fri, Jan 29, 2016 at 8:23 AM, Russ Housley <[email-masked]> wrote:

> Peter:
>
> > Russ Housley <housley at vigilsec.com> writes:
> >
> >> Take a look at this article: http://cryptosource.de/posts/
> smime_mta_en.html
> >>
> >> Is there interest in updating the S/MIME specification to use
> authenticated-
> >> encryption?
> >
> > It looks like a pretty contrived attack, you need to be able to truncate
> a
> > message, both at the start and end, on a 16-byte boundary to turn a
> signed
> > message into a plain, unsigned one, and still have the client accept the
> > result as a valid message.  They found one client that does that, but
> that
> > sounds more like a buggy client than a major problem (none of the others
> did
> > it).
> >
> > In any case the fix should be pretty minimal, if anything is required at
> all:
> > If the SMIMECaps in the cert you're encrypting for indicates authEnc, use
> > that.  My code already does that and possibly other impementations do
> too.
>
> CMS already supports Enveloped-Data and Authenticated-Enveloped-Data.
> However, the S/MIME specification does not say how to use
> Authenticated-Enveloped-Data.  I think that is the work to be done.
>
> Russ
>

---

From: Russ Housley <[email-masked]>
Date: Tue, 8 Mar 2016 01:58:34 -0500

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?

Is this enough to re-charter the S/MIME WG?

Russ

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 8 Mar 2016 17:07:32 +0000

> (5) Specify a way to use PGP public keys in addition to PKIX certificates.

It would be good if "Domain-based signing and encryption using S/MIME"
(draft-melnikov-smime-msa-to-mda-04) can also be included.

> Is this enough to re-charter the S/MIME WG?

I think so!

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 8 Mar 2016 13:16:49 -0500

> (5) Specify a way to use PGP public keys in addition to PKIX certificates.

If we are going to do this, I would like to also look at automating
enrollment for a CA issued certificate.

The biggest barrier to S/MIME use today is not the cost of the cert.
Comodo has tried giving them away for free for years. It is the
difficulty of using them that is the problem.

In my demonstration of the Mathematical Mesh, I show how to make
configuring S/MIME with a self-signed certificate so easy that the
user barely needs to be aware that it is happening.

In principal configuring a CA issued cert only requires one additional
piece of information, the DNS name of the CA to request the cert from
(and potentially there would be payment issues).

That said, I will note that items 1,2,3,4 are arguably already in
scope for CURDLE.

I am a big fan of doing (5). the point is to get people using end to
end encryption, not use one particular approach.

---

From: Russ Housley <[email-masked]>
Date: Tue, 8 Mar 2016 18:26:14 -0500

> enrollment for a CA issued certificate.

I agree that getting and renewing the certificate is far too difficult.

[snip]

> That said, I will note that items 1,2,3,4 are arguably already in

To use RFC 5083 and RFC 5084, we need to do quite a bit more than just add algorithms to a registry.  In my opinion, we would need to produce S/MIME) Version 3.3.

5083 Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data
     Content Type. R. Housley. November 2007. (Format: TXT=22810 bytes)
     (Updates RFC3852) (Status: PROPOSED STANDARD) (DOI:
     10.17487/RFC5083) 

5084 Using AES-CCM and AES-GCM Authenticated Encryption in the
     Cryptographic Message Syntax (CMS). R. Housley. November 2007.
     (Format: TXT=21821 bytes) (Status: PROPOSED STANDARD) (DOI:
     10.17487/RFC5084)

> end encryption, not use one particular approach.

At least one person agrees.  That is how it got on the list.

Russ

---

From: Sean Turner <[email-masked]>
Date: Wed, 9 Mar 2016 11:50:35 +0900

On Mar 09, 2016, at 08:26, Russ Housley <[email-masked]> wrote:
> 
>  In my opinion, we would need to produce S/MIME) Version 3.3.

I was thinking the same thing, but I’d call it S/MIME 4.0.

spt

---

From: Blake Ramsdell <[email-masked]>
Date: Tue, 8 Mar 2016 19:21:28 -0800

On Mon, Feb 1, 2016 at 3:02 PM, Sean Turner <[email-masked]> wrote:
> 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.

I am also willing to help.

And I agree that we need to do some outreach to get implementers
engaged and participating.

---

From: Russ Housley <[email-masked]>
Date: Tue, 8 Mar 2016 23:53:33 -0500

> (draft-melnikov-smime-msa-to-mda-04) can also be included.

Can you summarize the things that you need that are not supported by RFC 3183?

3183 Domain Security Services using S/MIME. T. Dean, W. Ottaway. October
     2001. (Format: TXT=57129 bytes) (Status: EXPERIMENTAL) (DOI:
     10.17487/RFC3183) 

Russ

---

From: Wei Chuang <[email-masked]>
Date: Thu, 10 Mar 2016 11:12:46 -0800

> (5) Specify a way to use PGP public keys in addition to PKIX certificates.

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...)

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

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 Mar 2016 12:50:45 +0000

Hi Russ,

>       2001. (Format: TXT=57129 bytes) (Status: EXPERIMENTAL) (DOI:
My draft is effectively a revision of RFC 3183:

Changes from RFC 3183

    Unlike RFC 3183, subject names of domain signing/encrypting X.509
    certificates don't have to have a specific form.  But Subject
    Alternative Names need to include URIs for domain being protected.

    A new signature type was added for the case when MSA signs/encrypts a
    message on behalf of a user with a user specific key.

    Incorporated erratum 3757 resolution.

    Updated references and some minor editorial corrections.

---

From: Sean Leonard <[email-masked]>
Date: Sat, 12 Mar 2016 22:38:11 -0800

> engaged and participating.

I suppose as an implementer who has been engaged and participating, I 
should volunteer to help as well. So, count me in.

If a new cryptographic mode is in-scope (which it is), I believe Version 
3.3 is not enough. I am in the Version 3.5 camp, if not the 4.0 camp.

Sean

---

From: Wei Chuang <[email-masked]>
Date: Sun, 13 Mar 2016 09:38:45 -0700

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

---

From: Wei Chuang <[email-masked]>
Date: Sat, 26 Mar 2016 06:57:15 -0700

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-masked]> wrote:

> - 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.

---

From: Sean Turner <[email-masked]>
Date: Mon, 28 Mar 2016 09:10:32 -0400

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-masked]> 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. 
> * A better mechanism than sign-encrypt-sign to get both authentication and confidentiality (or at least a non-strippable way of doing it)
> * 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
> 
> 
> 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
> 
> 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...)
>  
>

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 28 Mar 2016 09:49:00 -0700

> 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-masked]] On Behalf Of Sean Turner
> Sent: Monday, March 28, 2016 6:11 AM
> To: Wei Chuang <[email-masked]>
> Cc: IETF SMIME <[email-masked]>
> Subject: Re: [smime] Message takeover attacks against S/MIME
> 
> wishes to avoid the rough and tumble of discussion on the mailing list though
> reads it):
> > * 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
> >
> >
> > 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
> 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
> >
> > 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...)
> >
> >

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 29 Mar 2016 10:25:33 +0200

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

Erik

-----Oprindelig meddelelse-----
Fra: smime [mailto:[email-masked]] På vegne af Jim Schaad
Sendt: 28 March 2016 18:49
Til: 'Sean Turner' <[email-masked]>; 'Wei Chuang' <[email-masked]>
Cc: 'IETF SMIME' <[email-masked]>
Emne: Re: [smime] Message takeover attacks against S/MIME

jim

> Rex in the thread "another attempt to canonicalize local parts" that 
> missing CA certs and no ability to fetch them.  Fully specifying the 
> > 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.
> >
> > (4) Specify conventions for using the CFRG chosen curves for 
> > elliptic curve
> digital signature.
> >
> > 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
> >

---

From: Wei Chuang <[email-masked]>
Date: Tue, 29 Mar 2016 07:50:22 -0700

On Mon, Mar 28, 2016 at 9:49 AM, Jim Schaad <[email-masked]> wrote:

> 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.
>

(Caveat: I'm not familiar with these techniques, and am posting in part to
learn if this is a good idea.)

Have folks here considered authenticated key exchange to generate per
message symmetric key for AEAD?  Making the exchange asynchronous appears
to be possible as was done in TextSecure.  There more description in the
SoK paper (link <http://cacr.uwaterloo.ca/techreports/2015/cacr2015-02.pdf>)
around 13-16.  Criticism of TextSecure suggest though, the pre-keying could
cause problems for email applications.

-Wei

> > If the patient is on the table, then all of these look like items we’d
> need to
> > address.
> >
> > spt
> >
> though
> could be
> i.e.
> > > I am hearing interest in these topics (a combination of things on this
> list and
> > side conversations).
> > >
> > > (4) Specify conventions for using the CFRG chosen curves for elliptic
> curve
> > digital signature.
> > >

---

From: Russ Housley <[email-masked]>
Date: Tue, 29 Mar 2016 13:39:23 -0400

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 <[email-masked]> wrote:

>> need to address.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 29 Mar 2016 17:13:51 -0700

The one change that might hit CMS is the ability to use PGP keys.  It
depends on if we want to do this just for encryption or for both encryption
and signing.

Jim

> From: smime [mailto:[email-masked]] On Behalf Of Russ Housley
> Sent: Tuesday, March 29, 2016 10:39 AM
> To: Erik Andersen <[email-masked]>
> 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
> 
> 
> > I am open to suggestions, but until somebody gives be a better answer I
do not
> know how to do the following:
> >
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.
> >> wishes to avoid the rough and tumble of discussion on the mailing
> >> list though reads it):
i.e.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 30 Mar 2016 11:23:08 +0000

Jim Schaad <[email-masked]> writes:

>The one change that might hit CMS is the ability to use PGP keys.  It depends
>on if we want to do this just for encryption or for both encryption and
>signing.

What would prevent you from using them right now?  I've been using (or at
least suppoting the use of) PGP keys for CMS for years, you just use the key
ID instead of the (absent) issuerAndSerialNumber.

The reason for the "supporting the use of" is that I don't think anyone
actually cares about using PGP keys for CMS/SMIME.  Is there any actual demand
for it?

Peter.

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 31 Mar 2016 15:03:13 -0400

Are we discussing the IETF's CMS or
the ITU-T's just adopted version as
X.894?
--tony

-- 

________________________________ **

*Anthony Michael Rutkowski*

EVP, Industry Standards & Regulatory Affairs

[email-masked] <mailto:[email-masked]>

+1 703 999 8270 <tel:+1%20703%20999%208270>

________________________________ **

*Yaana Technologies LLC *

542 Gibraltar Drive

Milpitas CA 95035 USA

---

From: Russ Housley <[email-masked]>
Date: Thu, 31 Mar 2016 15:21:20 -0400

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-masked]> wrote:

> ________________________________
> 
> Anthony Michael Rutkowski
> 
> [email-masked]
> +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-masked]