Subject: [Endymail] Improvements to S/MIME

From: Wei Chuang <[email-masked]>
Date: Fri, 12 Sep 2014 10:48:07 -0700

Hi all,

I would like to propse that endymail list seems like a good place to
compile future IETF work for improving S/MIME (RFC5751).  I know the S/MIME
WG has been concluded for awhile, and it would be uncertain as to when such
work could be done, but perhaps if there is enough interest, then something
could be spun up.

For quiet awhile I've been wondering about two issues with S/MIME, (and if
I'm mistaken I would love to hear the solution):
1) S/MIME doesn't fully protect users mail envelope metadata.  For example
the recipient and envelope-sender must be visible to the intermediate SMTP
MTA servers or even in the clear if the transport isn't over TLS.  Could
work be done to allow for anonymize the sender and recipient to a domain
level?
2) The sender can't really specify to the recipient a forwarding/reply
security and privacy policy.  For example the sender may wish that
subsequent derivative mails be signed/encrypted, done so with a minimum
ciphers, or perhaps even request that no forwarding be done.  Should there
be work to describe a recommended security policy to the recipients?

thanks,
-Wei

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 12 Sep 2014 18:12:30 +0000

Just a question... I heard someone say at one IETF conference that S/MIME is the only standard with more implementations than users. Why has it suffered that fate? Surely not because of the two problems you mention.

Arnt

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Sep 2014 11:26:42 -0700

On 9/12/2014 10:48 AM, Wei Chuang wrote:
> compile future IETF work for improving S/MIME (RFC5751).

Let me suggest that there is a task that needs to come before that.  The
task is gaining agreement on the nature of the operation of end2end
encryption and how it might be different from previous operations.

Think of it as a meta-gap analysis, since it would not be specific to
s/mime.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Sep 2014 11:35:54 -0700

On 9/12/2014 11:12 AM, Arnt Gulbrandsen wrote:
> Just a question... I heard someone say at one IETF conference that
> S/MIME is the only standard with more implementations than users. Why
> has it suffered that fate? Surely not because of the two problems you
> mention.

Generic discussions about challenges in gaining use of end2end security
at Internet scale seem to be applicable to S/Mime.

They note:

   1.  We don't have an existence proof for workable key management at
scale.

   2.  We don't have an existence proof for usability (UX, HCI, etc.) at
Internet scale, which means workable for non-geeks who have no extra
motivation.

d/

---

From: Wei Chuang <[email-masked]>
Date: Fri, 12 Sep 2014 11:51:34 -0700

On Fri, Sep 12, 2014 at 11:12 AM, Arnt Gulbrandsen <[email-masked]
> wrote:

> Just a question... I heard someone say at one IETF conference that S/MIME
> is the only standard with more implementations than users. Why has it
> suffered that fate? Surely not because of the two problems you mention.

My two problems relate to privacy problems I see with S/MIME.   More to
your point, if you can make concrete the issues that cause lack of S/MIME
usage, those can be added to the list and the community will prioritize the
list by importance.

-Wei

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 12 Sep 2014 14:52:24 -0400

> Internet scale, which means workable for non-geeks who have no extra

For once I agree with Dave, sort of.

It is important to keep note of such issues. But solving them is not
very difficult. Making S/MIME cover the whole message is trivial: Just
extract the whole message including the content headers, encrypt it
and stick it in an attachment. Job done.

The only problem here then is knowing if the recipient supports this
S/MIME format. Which is one of the systemic problems that makes S/MIME
unusable: there is no negotiation mechanism and no way for the sender
to know what the receiver can accept. There are many pieces of data a
sender needs to know:

1) Should encryption be used in preference to plaintext?
2) Does the receiver support AES?
3) Does the receiver support PGP message format?
4) Does the receiver support S/MIME message format?
5) Versions, options on the above.

But what is critical is that if we do end up deploying one of the
proposals that solves these problems - and we already have a working
proof of concept, we have to make sure that the 'encrypt entire
message' issue is not forgotten.

But given that PGP has the same problem, I think this particular
feature could well be a point that gets the two camps to agree on
convergence. Because surely we can all agree that not encrypting the
subject line was a ridiculous limitation that makes the specs toybox
implementations.

---

From: Werner Koch <[email-masked]>
Date: Sat, 13 Sep 2014 19:54:02 +0200

> the recipient and envelope-sender must be visible to the intermediate SMTP

If you want that, it is easy to put the messaqge into a message/rfc822
mail container and use faked subject and other mailer header.

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 13 Sep 2014 14:46:25 -0400

> mail container and use faked subject and other mailer header.

Again there is a difference between what you can do and a standard.

I think that 80% of what we need to do could be done in a profile of
S/MIME that says stuff like

* MUST support AES-128, AES-256
* MUST support [choose order of encrypt + sign]
* MUST support domain level certs for end entity
* MUST support message/rfc822 encrypted payload

What we need to add on top is really not so difficult:

* Mechanism for discovering recipient encryption preference, format
support (PGP/SMIME), algorithm support and encryption key
* Mechanism for direct trust, aka key fingerprint
* Mechanism for private key maintenance

But for any of it to work, we all have to do the same thing.

---

From: Wei Chuang <[email-masked]>
Date: Sun, 14 Sep 2014 01:13:07 -0700

> mail container and use faked subject and other mailer header.

Right I agree that there is a RFC5751 sec 3.1 (
http://tools.ietf.org/html/rfc5751#page-18 ) that mentions the
message/rfc822, but unless I'm missing something one still has to specify
the intended recipient, and a return path.  Even if the body and most
headers were wrapped hence private, an adversary could still find the
sender/recipient information very useful.

Another issue albeit a small one with message/rfc822, was what to do if the
headers conflicted between the outer and inner messages.

-Wei

---

From: Wei Chuang <[email-masked]>
Date: Sun, 14 Sep 2014 01:21:19 -0700

> support (PGP/SMIME), algorithm support and encryption key

Two ideas:
1) DNS (either new TXT entry or new record type)
2) EHLO SMTP extension

> * Mechanism for private key maintenance

Is this issue key rotation?

-Wei

---

From: Werner Koch <[email-masked]>
Date: Sun, 14 Sep 2014 11:02:52 +0200

> the intended recipient, and a return path.  Even if the body and most

Mixmaster does this for ages.  Mutt has support for Mixmaster for more
than 15 years.  Changing this to work at all levels using MIME
containers won't be too hard.  For stronger anonymity the MTAs may use
TOR or similar.  Agreed, this is not a problem of standards but of doing
the work.

Salam-Shalom,

   Werner

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 14 Sep 2014 09:46:17 -0400

On Sun, Sep 14, 2014 at 4:13 AM, Wei Chuang <[email-masked]> wrote:
> Right I agree that there is a RFC5751 sec 3.1
> (http://tools.ietf.org/html/rfc5751#page-18 ) that mentions the

I suggest that we stick to exchanging endymail with disclosure of the
routing information before we go on to the traffic analysis prevention
problem.

It is possible to prevent traffic analysis but that is a transport
issue pretty much by definition. So it would suggest we look at S/MIME
+ TLS rather than one alone. And if they don't serve then we look at
Tor and Mixmaster...

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 14 Sep 2014 10:14:49 -0400

Hi Wei,

> 1) DNS (either new TXT entry or new record type)

What about Webfinger - RFC7033?

-- 
Cyrus Daboo

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 14 Sep 2014 10:26:06 -0400

> What about Webfinger - RFC7033?

Well design of a JSON Web Service is hardly difficult.

Webfinger infrastructure might be one of the places we look for
information, so is the DNS, so is the emergent Trans notary
infrastructure.

First we should decide on what the information flows between the
client and service need to be. Then we can decide what the realization
should be.

A Web Service is just an API after all, reuse of an API is sometimes
good and sometimes very bad. Trying to reuse a 2D API for 3D graphics
was a very bad plan for the company that tried it.

---

From: Tom Mitchell <[email-masked]>
Date: Sun, 14 Sep 2014 21:21:27 -0700

On Sun, Sep 14, 2014 at 6:46 AM, Phillip Hallam-Baker <[email-masked]

> > (http://tools.ietf.org/html/rfc5751#page-18 )
>
...........

> routing information before we go on to the traffic analysis prevention

Yes...
One of the issues important hint for spam identification is routing
information that  is impossible
from the stated sender.   Prior to eliminating routing information it seems
important that
the message be self identifying and contain enough validation information
to make opening
a message from "Bob" a safe bet that it is infact from "Bob".  If done
correctly transport
software can inspect a message and safely ignore adding or checking headers
because
crypto and message type removes this need.

The reverse is not true as it opens a door for spam abuse.

-- 
  T o m    M i t c h e l l

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 15 Sep 2014 00:25:20 -0400

On Mon, Sep 15, 2014 at 12:21 AM, Tom Mitchell <[email-masked]> wrote:
> On Sun, Sep 14, 2014 at 6:46 AM, Phillip Hallam-Baker
> <[email-masked]> wrote:
>>
> the message be self identifying and contain enough validation information to
> make opening

That is a good argument, but the one I was making is that we can't
hope to solve routing security anyway unless we have volume.

It is much easier to hide in a jungle or a forest than a flat featureless plain.

---

From: Wei Chuang <[email-masked]>
Date: Mon, 15 Sep 2014 01:38:38 -0700

On Sun, Sep 14, 2014 at 7:26 AM, Phillip Hallam-Baker <[email-masked]

> > What about Webfinger - RFC7033?

Agreed another idea to examine (as all have interesting trade offs).

> information, so is the DNS, so is the emergent Trans notary

This is related to Certificate Transparency right?  Granted I'm not really
that familiar with CT which I had thought was for attestation of the
validity of a certificate.  Is there a pointer to some discussion /
description on how one might use the Trans Notary infrastructure to
broadcast the configuration information?

-Wei

---

From: Wei Chuang <[email-masked]>
Date: Mon, 15 Sep 2014 01:50:51 -0700

> * Mechanism for private key maintenance

It occurs to me that acceptable X509 certificate profiles could be another
i.e. does recipient require
- CA path constraints
- support certain revocation methods
- accepted x509 versions, signature algorithm+keylength
- accepted root CAs
etc.

-Wei

---

From: Wei Chuang <[email-masked]>
Date: Tue, 16 Sep 2014 10:06:04 -0700

On Sun, Sep 14, 2014 at 1:13 AM, Wei Chuang <[email-masked]> wrote:

> Another issue albeit a small one with message/rfc822, was what to do if
> the headers conflicted between the outer and inner messages.
>

Just wanted to point out that wrapping using message/rfc822 may have
problems.  In another thread regarding DMARC damage, one proposed
mitigation is also to wrap the message but was noted that this could open
the recipient to phishing attacks due to mishandling of headers by the
recipients MUA.

See http://www.ietf.org/mail-archive/web/ietf/current/msg89601.html

John Levine suggested there using other options for mitigating against
DMARC.  In the S/MIME context I don't think that's possible to avoid
wrapping if one wants to protect the headers, so work will have to be done
to prevent opening a phishing vector.

-Wei