Subject: [lamps] S/MIME fix

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 May 2018 10:28:59 -0400

Looking at eFail, surely the simplest fix is to require that an HTML
message body be presented in a single CMS envelope presented in a single
MIME part?

This would simplify the code substantially. While it is conceivable someone
has worked out a way to make use of this mis-feature, I for one cannot
imagine why Outlook, Thunderbird or the like would ever do anything of the
sort.

Separately, we have interest in CAA for S/MIME. Surely we should do ACME
for S/MIME as well. If we are going to do that, surely we should have a
discussion of what it would take to make end to end security the default
for SMTP.

I am not necessarily thinking of this as a LAMPS thing because we also need
to get CAs, probably CABForum involved and maybe the OpenPGP folk.

The model we have right now is that we have a lot of different camps
offering technology. Some of that technology meets the needs of a
particular community. What we do not have is a general solution or a mass
deployment strategy.

And this is really important because email security breaches have changed
the course of history in the past few months.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 16 May 2018 15:48:54 +0100

Hi Philip,

On 16/05/2018 15:28, Phillip Hallam-Baker wrote:
> message body be presented in a single CMS envelope presented in a 
> single MIME part?

I am not sure what you mean here. A CMS envelope can contain 
multipart/mixed within it, which is a perfectly valid use case (i.e. if 
one wants to send some encrypted text together with some encrypted 
attachments).
If you are talking about preventing the following construct:

content-type: multipart/mixed; 
boundary=.f8231d7f-681b-442c-97cc-e6c5375d059d

This is a multipart message in MIME format.

--.f8231d7f-681b-442c-97cc-e6c5375d059d
content-type: text/html

...some partial HTML...
--.f8231d7f-681b-442c-97cc-e6c5375d059d
content-disposition: inline; filename=smime.p7m
Content-Transfer-Encoding: base64
content-type: application/pkcs7-mime; name=smime.p7m; smime-type=enveloped-data

...encrypted HTML...
--.f8231d7f-681b-442c-97cc-e6c5375d059d
content-type: text/html

...some partial HTML...
--.f8231d7f-681b-442c-97cc-e6c5375d059d--

i.e. a multipart/mixed that contains a mixture of text/html and 
application/pkcs7-mime, then I might agree with you. But this is not 
really an S/MIME feature, it is a generic MIME feature. So maybe this WG 
should write a document on best S/MIME implementation practices.

> This would simplify the code substantially. While it is conceivable 
> someone has worked out a way to make use of this mis-feature, I for 
> one cannot imagine why Outlook, Thunderbird or the like would ever do 
> anything of the sort.
>
>
> Separately, we have interest in CAA for S/MIME. Surely we should do 
> ACME for S/MIME as well.

Not surprisingly, I agree. See draft-ietf-acme-email-smime-02
> If we are going to do that, surely we should have a discussion of what 
> it would take to make end to end security the default for SMTP.
>
> I am not necessarily thinking of this as a LAMPS thing because we also 
> need to get CAs, probably CABForum involved and maybe the OpenPGP folk.

Best Regards,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 16 May 2018 15:53:39 +0100

On 16/05/2018 15:48, Alexey Melnikov wrote:

> multipart/mixed within it, which is a perfectly valid use case (i.e. 
> if one wants to send some encrypted text together with some encrypted 
> attachments).
> application/pkcs7-mime, then I might agree with you.
Implementations that can validate HTML should check that each body part 
contains valid HTML. So if it detects partial HTML, it should reject 
displaying it or concatenating it into a single HTML object that might 
end up syntactically valid.

> But this is not really an S/MIME feature, it is a generic MIME 
> feature. So maybe this WG should write a document on best S/MIME 
> implementation practices.

---

From: Jim Schaad <[email-masked]>
Date: Wed, 16 May 2018 10:35:59 -0700

I will note that unless multipart/mixed has some special text associated with it.  Text/html is defined by RFC 1866 to only hold a single HTML document.  Thus building an HTML document from multiple parts is not according to Hoyle.

Jim

From: Spasm <[email-masked]> On Behalf Of Alexey Melnikov
Sent: Wednesday, May 16, 2018 7:49 AM
To: Phillip Hallam-Baker <[email-masked]>; SPASM <[email-masked]>
Subject: Re: [lamps] S/MIME fix

Hi Philip,

Looking at eFail, surely the simplest fix is to require that an HTML message body be presented in a single CMS envelope presented in a single MIME part?

I am not sure what you mean here. A CMS envelope can contain multipart/mixed within it, which is a perfectly valid use case (i.e. if one wants to send some encrypted text together with some encrypted attachments).
If you are talking about preventing the following construct:

content-type: multipart/mixed; boundary=.f8231d7f-681b-442c-97cc-e6c5375d059d

 
....some partial HTML...
 
....encrypted HTML...
 
....some partial HTML...

i.e. a multipart/mixed that contains a mixture of text/html and application/pkcs7-mime, then I might agree with you. But this is not really an S/MIME feature, it is a generic MIME feature. So maybe this WG should write a document on best S/MIME implementation practices.

This would simplify the code substantially. While it is conceivable someone has worked out a way to make use of this mis-feature, I for one cannot imagine why Outlook, Thunderbird or the like would ever do anything of the sort.

Separately, we have interest in CAA for S/MIME. Surely we should do ACME for S/MIME as well.

If we are going to do that, surely we should have a discussion of what it would take to make end to end security the default for SMTP.

I am not necessarily thinking of this as a LAMPS thing because we also need to get CAs, probably CABForum involved and maybe the OpenPGP folk.

Best Regards,
Alexey

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 May 2018 13:45:01 -0400

On Wed, May 16, 2018 at 10:48 AM, Alexey Melnikov <[email-masked]
> wrote:

> multipart/mixed within it, which is a perfectly valid use case (i.e. if one
> wants to send some encrypted text together with some encrypted attachments).
>

​Agreed.

​

> application/pkcs7-mime, then I might agree with you. But this is not really
> an S/MIME feature, it is a generic MIME feature. So maybe this WG should
> write a document on best S/MIME implementation practices.
>

​Agreed. It is a feature of MIME which seems to have been carried over to
S/MIME without people asking WTF?​

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 16 May 2018 18:51:32 +0100

On 16/05/2018 18:35, Jim Schaad wrote:

> I will note that unless multipart/mixed has some special text 
> associated with it.  Text/html is defined by RFC 1866 to only hold a 
> single HTML document.  Thus building an HTML document from multiple 
> parts is not according to Hoyle.
>
Yes, but people do this anyway, as separate HTML body parts are 
frequently valid HTML documents. So building from pieces works most(*) 
of the time.

(*) spam and phishing nonwithstanding.
>
>
> Jim
>
> *From:*Spasm <[email-masked]> *On Behalf Of *Alexey Melnikov
> *Sent:* Wednesday, May 16, 2018 7:49 AM
> *To:* Phillip Hallam-Baker <[email-masked]>; SPASM <[email-masked]>
> *Subject:* Re: [lamps] S/MIME fix
>
> Hi Philip,
>
>     Looking at eFail, surely the simplest fix is to require that an
>     HTML message body be presented in a single CMS envelope presented
>     in a single MIME part?
>
>
> really an S/MIME feature, it is a generic MIME feature. So maybe this 
> WG should write a document on best S/MIME implementation practices.
>
>
>     This would simplify the code substantially. While it is
>     conceivable someone has worked out a way to make use of this
>     mis-feature, I for one cannot imagine why Outlook, Thunderbird or
>     the like would ever do anything of the sort.
>
>     If we are going to do that, surely we should have a discussion of
>     what it would take to make end to end security the default for SMTP.
>
>     I am not necessarily thinking of this as a LAMPS thing because we
>     also need to get CAs, probably CABForum involved and maybe the
>     OpenPGP folk.
>
>
> Best Regards,
> Alexey
>

---

From: Tim Hollebeek <[email-masked]>
Date: Wed, 16 May 2018 19:59:40 +0000

It’s not necessarily an either / or thing.  After July 3, we’ll have a S/MIME group at CABF and from talking privately to some people it sounds like we will have good participation.  But that will mostly be a policy discussion.

It would be nice to have IETF RFCs to point to for all the persnickety technical details about how things like ACME and CAA work with email.  I’m sure there’s plenty of nuances we haven’t thought of yet.  There certainly were for the web.

Draining the email swamp is actually very high on my priority list for this year.

-Tim

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 May 2018 16:55:21 -0400

Absolutely, it is not either/or.

What I would like to see us do however is come together at some point and
identify ALL the issues that are barriers to ubiquitous deployment of
S/MIME and come up with a comprehensive scheme.

What I think we are going to need is a standard that allows folk to know if
their infrastructure supports S/MIME-NG.

On Wed, May 16, 2018 at 3:59 PM, Tim Hollebeek <[email-masked]>
wrote:

> It’s not necessarily an either / or thing.  After July 3, we’ll have a
> S/MIME group at CABF and from talking privately to some people it sounds
> like we will have good participation.  But that will mostly be a policy
> discussion.
>
>
>
> It would be nice to have IETF RFCs to point to for all the persnickety
> technical details about how things like ACME and CAA work with email.  I’m
> sure there’s plenty of nuances we haven’t thought of yet.  There certainly
> were for the web.
>
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 May 2018 22:16:37 +0100

> S/MIME and come up with a comprehensive scheme.

I agree with the above, so long as we don't exclude PGP. (There
are pros and cons to both.)

I'd be willing to do work to try even get consensus on the barriers
to large scale usage for e2e email security. (A list of those that
I use in class is below - I don't claim that's the best possible
list.)

That said, I'm not so optimistic as I think some of those barriers
are currently insurmountable. Still willing for another tilt at the
windmill though. I don't think that ought be a formal anything
at the next IETF meeting - I can't see us making progress with 40+
people in a room, so something with a much smaller number would be
needed to start. If someone does organise such, I'd be happy to
join in if the set of folks includes at least one of the main
players in email - if there're none of those involved, it's
probably not even worth tilting at, is my gloomy conclusion.

Cheers,
S.

- Designs pre-date web user agent which changes trust model
(where's the private key kept? Needs new infrastructure)
- Needs all major email service providers (yahoo, hotmail, gmail)
to deploy the same thing which also needs to be implemented
by all major user agent developers (microsoft, mozilla, apple,
google)
- Public key retrieval needs to be fixed (doable if the above done,
but a killer if not done), likely with some new PKI (doable but
who's gonna pay?)
- Mail headers need to be protected as users don't get that
S/MIME and PGP only protect body and not e.g. Subject, From
(new enveloping protocol needed, can be done but kludgy)
- We need to unify S/MIME and PGP or pick one or we'll lose
interop (it's ok if the other soldiers on for some niches)
- Users don't care much, so it has to be entirely transparent for
them (needs signifcant UI work, co-ordinated across MUAs and
signifcant web-UAs)

---

From: Adam Roach <[email-masked]>
Date: Wed, 16 May 2018 17:32:41 -0500

> (where's the private key kept? Needs new infrastructure)

To understand the challenges surrounding what you suggest, you probably 
want to study the issues surrounding isolated media streams in WebRTC. 
Start by looking at section 4.3.2.4 of draft-ietf-rtcweb-security, and 
then read through <https://www.w3.org/TR/webrtc/#isolated-media-streams>.

To create an analogous situation for secure email, you'd need to use 
webcrypto in a way that stored your private key in the browser 
(inaccessible to the page), and develop web standards that add some 
affordance for web pages to hand encrypted data to the browser in a way 
that causes the corresponding unencrypted data to be displayed to the 
user, but isolated from the web page completely (e.g., rendered into an 
iframe that the parent cannot inspect).

Whether that kind of isolated context for email (which should be usable 
for real-time messaging as well, if done correctly) is reasonable or too 
clunky to work is yet to be seen. (I've had a few conversations that 
concluded "too clunky," but reasonable people may disagree.) In any 
case, the bulk of the work for that kind of system would need to take 
place in the W3C.

There are, of course, possible trade-offs to be made in which the user 
trusts the web-hosted mail service with access to message plain text, or 
even to their private key; but once you take that leap, you're doing 
scantly better than the hop-by-hop security provided by DANE and/or MTA-STS.

/a

---

From: Tim Hollebeek <[email-masked]>
Date: Wed, 16 May 2018 23:36:41 +0000

This is interesting, I hadn't thought of the parallels with WebRTC, despite 
the fact that I've given a talk on the fact that all of these things are 
basically the same problem.

I have a soft spot for the WebRTC security stuff.  It really is far more 
elegant and well designed than it initially appears.  It's not perfect, but 
it's worth looking at closely and thinking carefully about.

-Tim

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]]
> Sent: Wednesday, May 16, 2018 6:33 PM
> To: Stephen Farrell <[email-masked]>; Phillip Hallam-Baker
> <[email-masked]>; Tim Hollebeek <[email-masked]>
> Cc: SPASM <[email-masked]>
> > - Designs pre-date web user agent which changes trust model (where's
> > the private key kept? Needs new infrastructure)
>
>
> Start by looking at section 4.3.2.4 of draft-ietf-rtcweb-security, and then 
> read
> through <https://clicktime.symantec.com/a/1/ZUvdrU2DWW-aLe1I1x-
> uWvB_9Olp-hukiQj_tS5vyo4=?d=J11B9dbh9pdZkagcAZSOz6N-
> lMrt249fI1GArrhjTyT2Mv0bxRlEJ34cZbS87eUKrlHkdxKTyM16fzk6Oa2cbNkCsS6
> T7wEgMqMBZ7jiNVeZi__gmD30Y7U3ikHJyMppa7BM6IWhNCSXAbGI1SCtQpF9
> pZ2hlFhqpJrzzXd65YdPDL9iwlDdNbt72F5wUNK26Zb-
> sF9hbGrLwyarefR9gaWnh15R3EjJ-
> OqlLE4CDFWsBJGSxmMLBvwj263QrMrRM72PJxKZU3XFmsj9e3cEupBLjH6N0QX
> oLmMD42i2wt0MnYSoCtKaiTWzTg33hRlj8XVNAc32mj0D-
> o18pnLVxHi2q9Nbdn3kYxepwnSq&u=https%3A%2F%2Fwww.w3.org%2FTR%2F
> webrtc%2F%23isolated-media-streams>.
>
> webcrypto
> in a way that stored your private key in the browser (inaccessible to the 
> page),
> and develop web standards that add some affordance for web pages to hand
> encrypted data to the browser in a way that causes the corresponding
> unencrypted data to be displayed to the user, but isolated from the web page
> completely (e.g., rendered into an iframe that the parent cannot inspect).
>
> Whether that kind of isolated context for email (which should be usable for
> real-time messaging as well, if done correctly) is reasonable or too clunky 
> to
> work is yet to be seen. (I've had a few conversations that concluded "too
> clunky," but reasonable people may disagree.) In any case, the bulk of the 
> work
> for that kind of system would need to take place in the W3C.
>
> trusts
> the web-hosted mail service with access to message plain text, or even to 
> their
> private key; but once you take that leap, you're doing scantly better than 
> the
> hop-by-hop security provided by DANE and/or MTA-STS.
>
> /a

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 17 May 2018 00:42:03 +0100

On 16/05/18 23:32, Adam Roach wrote:
> To understand the challenges surrounding what you suggest,

Just to be clear - that was only a list of hard (or possibly
killer) problems with no solutions suggested.

I do agree with what you say below, though there could be
at least one more option which'd be to keep your private key(s)
for mail-message decryption on a key server (supposedly)
controlled by the user and to have all your MUAs talk to it
over some client-authenticated channel. Not saying that's any
better or more practical than the ones you describe below
though.

Cheers,
S

> you probably
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 17 May 2018 09:42:43 -0400

On May 16, 2018, at 1:51 PM, Alexey Melnikov <[email-masked]> wrote:
> Yes, but people do this anyway, as separate HTML body parts are frequently valid HTML documents. So building from pieces works most(*) of the time.
> 

I do not see a way to totally thwart eFail unless each portion of a multi-part is processed in its own sandbox.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 17 May 2018 10:01:52 -0400

Adam:
> To understand the challenges surrounding what you suggest, you probably want to study the issues surrounding isolated media streams in WebRTC. Start by looking at section 4.3.2.4 of draft-ietf-rtcweb-security, and then read through <https://www.w3.org/TR/webrtc/#isolated-media-streams>.

I see the parallel, and in fact, the biggest problem is the use of HTML that includes a reference to something that is outside the message itself.

> To create an analogous situation for secure email, you'd need to use webcrypto in a way that stored your private key in the browser (inaccessible to the page), and develop web standards that add some affordance for web pages to hand encrypted data to the browser in a way that causes the corresponding unencrypted data to be displayed to the user, but isolated from the web page completely (e.g., rendered into an iframe that the parent cannot inspect).

I am not following you.  I do not see the requirement to do anything with webcrypto.  However, I completely agree with the need to isolate each portion of the multi-part.

Russ

---

From: Adam Roach <[email-masked]>
Date: Thu, 17 May 2018 10:37:25 -0500

> I am not following you.  I do not see the requirement to do anything with webcrypto.  However, I completely agree with the need to isolate each portion of the multi-part.

Presumably, we would need a means to generate a keypair, and to make the 
public key available to the webpage so that it can be conveyed to remote 
parties. That could be a new API, but it feels like something that could 
be added to webcrypto without much fuss. (I'll note that WebRTC did take 
the other approach, by defining an 
RTCPeerConnection.generateCertificate() method that is very roughly 
equivalent to window.crypto.subtle.generateKey(), but with the 
properties I describe above).

Admittedly, this can all be done by the browser itself using local UI, 
but the general idea of the web platform is that you delegate only as 
little as is necessary to the browser. I mean, if you push enough of 
this to the local binary, and it becomes a full-fledged email client. ;)

/a

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 17 May 2018 11:46:21 -0400

On Thu, May 17, 2018 at 11:37 AM, Adam Roach <[email-masked]> wrote:

>>> that causes the corresponding unencrypted data to be displayed to the user,
>>> but isolated from the web page completely (e.g., rendered into an iframe
>>> that the parent cannot inspect).
>>>
>> I am not following you.  I do not see the requirement to do anything with
>> webcrypto.  However, I completely agree with the need to isolate each
>> portion of the multi-part.
>>
>
> parties. That could be a new API, but it feels like something that could be
> added to webcrypto without much fuss. (I'll note that WebRTC did take the
> other approach, by defining an RTCPeerConnection.generateCertificate()
> method that is very roughly equivalent to window.crypto.subtle.generateKey(),
> but with the properties I describe above).
>
> Admittedly, this can all be done by the browser itself using local UI, but
> the general idea of the web platform is that you delegate only as little as
> is necessary to the browser. I mean, if you push enough of this to the
> local binary, and it becomes a full-fledged email client. ;)

​That was the CERN approach.

Netscape disagreed, threw JavaScript together in a fortnight and launched
it on the world with no consultation. We have been in damage control ever
since.

A modern Web browser is a Turing complete language for constructing thick
clients for the Web Services of your choice. I don't like the fact but it
is what it is.

I am composing this in Gmail right now. And there is my outlook client in
the window underneath. ​The Web browser is not just a full fledged email
client, it is the client of choice.

---

From: Adam Roach <[email-masked]>
Date: Thu, 17 May 2018 10:51:44 -0500

On 5/17/18 10:46 AM, Phillip Hallam-Baker wrote:
> I am composing this in Gmail right now. And there is my outlook client 
> in the window underneath. ​The Web browser is not just a full fledged 
> email client, it is the client of choice.

I don't want to get too far down the rabbit hole of semantics here, but 
claiming that a browser is an email client because it can run Gmail is 
fully congruent with claiming your operating system is an email client 
because it can run Outlook.

More to the point: you know what I meant.

/a

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 17 May 2018 14:53:54 -0400

I'm having trouble understanding how the current discussion relates to the
LAMPS work. It sounds from Phil's initial message, is that this isn't
related to LAMPS. There's been suggestions that this might be the
CA/Browser Forum (despite the CA/Browser Forum not even having a proposed
charter to clean this up), that this might be a W3C/WHATWG issue (despite
the browsers explicitly rejecting some of these proposals), or perhaps
somewhere else.

For my own understanding, is there a concrete proposal for either a
document or work LAMPS should take on? Otherwise, would it be better to
have this discussion elsewhere?

---

From: Russ Housley <[email-masked]>
Date: Thu, 17 May 2018 14:58:01 -0400

Ryan:

It seems to me that the LAMPS WG should say something about how to avoid the eFail attack in the Security Considerations of draft-ietf-lamps-rfc5751.

Russ

> On May 17, 2018, at 2:53 PM, Ryan Sleevi <[email-masked]> wrote:
> 
> I'm having trouble understanding how the current discussion relates to the LAMPS work. It sounds from Phil's initial message, is that this isn't related to LAMPS. There's been suggestions that this might be the CA/Browser Forum (despite the CA/Browser Forum not even having a proposed charter to clean this up), that this might be a W3C/WHATWG issue (despite the browsers explicitly rejecting some of these proposals), or perhaps somewhere else.
> 
> For my own understanding, is there a concrete proposal for either a document or work LAMPS should take on? Otherwise, would it be better to have this discussion elsewhere?
> 
> On Thu, May 17, 2018 at 11:51 AM, Adam Roach <[email-masked] <mailto:[email-masked]>> wrote:
>> I am composing this in Gmail right now. And there is my outlook client in the window underneath. ​The Web browser is not just a full fledged email client, it is the client of choice.
> 
> I don't want to get too far down the rabbit hole of semantics here, but claiming that a browser is an email client because it can run Gmail is fully congruent with claiming your operating system is an email client because it can run Outlook.
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>
> 
>

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 17 May 2018 15:36:05 -0400

Sure, that part sounded uncontroversial. I was simply having a hard time
about the WebCrypto API or the philosophical differences of CERN and
Netscape's design philosophies was helping us move towards that. The
conversation from Jim and Alexey seemed a great path forward to exploring
that.

On Thu, May 17, 2018 at 2:58 PM, Russ Housley <[email-masked]> wrote:

> Ryan:
>
> It seems to me that the LAMPS WG should say something about how to avoid
> the eFail attack in the Security Considerations of draft-ietf-lamps-rfc5751.
>
> Russ
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 17 May 2018 16:00:48 -0400

I am not sure why this discussion would cause confusion as it is normal for
people to discuss the broad outlines of a proposal before writing text. It
is also common for people to discuss an emerging security issue in a
closely related working group before deciding on what the appropriate venue
to hold discussions in would be.

Even more so in this case since the problem and solution spaces are
strongly constrained and I suspect that there is a very wide range of
agreement about what needs to be done and how to approach a solution.

But if you will insist on Internet Drafts relevant to the subject matter,
you will find my proposals on the topic here:

http://mathmesh.com/Resources/

Since my design brief was to provide a proof of concept, I started from a
clean state and ignored existing work. Now that we have established that
transparent end-to-end security is possible we can look at what changes we
would need to make to the existing mail infrastructure to apply that
approach to legacy systems.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 17 May 2018 22:04:26 -0400

On Thu, May 17, 2018 at 9:42 AM, Russ Housley <[email-masked]> wrote:

> I will note that unless multipart/mixed has some special text associated
> with it.  Text/html is defined by RFC 1866 to only hold a single HTML
> document.  Thus building an HTML document from multiple parts is not
> according to Hoyle.
>
> Yes, but people do this anyway, as separate HTML body parts are frequently
> valid HTML documents. So building from pieces works most(*) of the time.
>
> I do not see a way to totally thwart eFail unless each portion of a
> multi-part is processed in its own sandbox.
>

​I concur with Russ on this. Though defining what a sandbox is may be a
challenge.​

​While I don't doubt that spammers are abusing multipart/related, is there
a circumstance in which an end user is likely to generate an email with
text/html split across several multipart/related blocks? I think that is
really rather unlikely.

The gadget attack is less of a concern to me since encryption never assures
authentication, thats why you need authenticated encryption or a MAC.

---

From: Russ Housley <[email-masked]>
Date: Fri, 18 May 2018 07:18:14 -0400

{ RETRANSMISSION due to the short mail list outage yesterday. }

Ryan:

Russ

> On May 17, 2018, at 2:53 PM, Ryan Sleevi <[email-masked] <mailto:[email-masked]>> wrote:
>