Subject: [perpass] Why Yaron can't encrypt: S/MIME in the real world

From: Yaron Sheffer <[email-masked]>
Date: Sat, 07 Sep 2013 16:39:18 +0300

Hi,

I have wanted to get my company on S/MIME for a while, and the recent 
noise was the final motivator I needed. We are a small company doing 
security, however (like anywhere else) not everybody can be considered a 
security "expert".

So Outlook and Thunderbird have good support for S/MIME. This is a good 
starting point, right? Personally I am using Thunderbird running on 
Linux, which has very convenient S/MIME support. I had actually used it 
in the past.

Below I will show that in today's market you simply cannot use S/MIME, 
because of a combination of bad security practices, silly web-site 
design, lousy CA support on Linux and probably a few more factors.

  * Started with the free options. The Web is full with tutorials on how
    to install the free Comodo email cert in your mail client. It turns
    out, with InstantSSL (Comodo) you cannot register twice with same
    email address (e.g. if the cert is lost for some reason or you just
    want to use two different machine without shuttling private keys
    around). The same is true for StartSSL.
  * Next tried Symantec: this is $22 per year, the UI is not very good
    (says cert is installed but then has a button to install cert). TB
    says the certificate could not be validated "for unknown reasons". I
    guess there is no valid certificate chain. Well, Symantec doesn't
    appear in either the Chromium/Linux or Firefox/Linux cert stores.
  * GlobalSign: EUR 12 for 1 yr, 29 for 3 yrs. Not too bad. So you go
    into their wizard. The default is that the private key is generated
    by the CA! Which means this product is not (securely) usable for
    multiple users in an organization. Most of them will probably leak
    their private key.
  * CACert: Free and open source. Probably still struggling (the server
    is extremely slow). Surprisingly, the CAcert root CA is known by
    Chromium/Linux but not by TB/Linux (stock Thunderbird on Ubuntu 12.04).
  * Entrust: pricing is only for US, UK and Canada. Other customers are
    referred to a small number of resellers (none for my geography).
    They still let you order the cert though. And then surprise! The $20
    price that appears on the "Buy Now" page turns into $30 when you
    complete filling the form.

This covers all I could find on the first 4 Google search pages for 
"email certificates". I will try again in a year or two.

Thanks,

     Yaron

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 07 Sep 2013 16:00:34 +0100

Fully agree with you. S/MIME as-is is not usable in the wild.
PGP is better, but I doubt its usable by an entire organisation
or set of home-users for most mail messages.

Let's posit an end goal where a large proportion of email ends
up with ciphertext bodies at least, but typically without a high
level of assurance that the right public key was used.

My questions:

1) Would we like to get there?
2) If we would, should we start from a) S/MIME or b) PGP or
   c) yet another mail-security clean slate?
3) If we got as far as having IETF consensus on something
   we think could do the above (i.e. we completed the RFCs
   for (2)), do we think there's any real chance that that
   could be deployed and end up widely used?

FWIW, my answers would be 1) yes, 2) (c), reluctantly, since
it'd only be worthwhile if it covered headers, and 3) "I very
much doubt it unfortunately."

I'd be surprised (but pleased) if we had a rough consensus on
these questions. And even more surprised and pleased if that
consensus indicated that there's an obvious thing that we
should start doing in the near future.

Sorry to be pessimistic, and I'd really love to be wrong, but
I can't see a realistic way to get e2e email confidentiality
out there as of now.

If the top-tier email providers got their act together on
something that didn't allow 'em to scan mail content (without
launching a MITM) then that'd change my pessimism. I guess
there is some chance of that, but I suspect that the
initiative for such a service-provider driven effort would
start outside the IETF (same as DKIM/DMARC).

S.

PS: Clarifications: SMTP/TLS with DANE is still worth doing
and is being done. S/MIME and PGP are quite usable within a
community or even large enterprise, but not on the big-I
Internet. e2e mail message signing is maybe more easily
doable but is uselessly boring IMO and not relevant for
perpass, so that's not a goal at all. And by e2e confid.
I mean that in almost all cases the private decryption
keys are only really usable/available to an MUA on the
user's machine and almost never on the MTA/MS.

On 09/07/2013 02:39 PM, Yaron Sheffer wrote:
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
> 
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 7 Sep 2013 11:43:04 -0400

> level of assurance that the right public key was used.

As it happens I have been working on a draft on Prism-Proofing email for a
couple of weeks now and was hoping to get an ID out with the idea of
proposing a BOF or something to the Security AD.

> 1) Would we like to get there?

I think we can do better than that. I have been looking at CT applying the
concept (but not the exact spec) to email.

But being able to send encrypted mail easily and being able to trust the
keys are two separable concerns.

Separating those concerns is what I was trying to do with XKMS but we never
got it hooked into email clients and now the fashion is for JSON rather
than XML (which I think is a good thing)

>    c) yet another mail-security clean slate?

Please lets not rehash the message format. S/MIME has won the encrypted
mail message format and PKIX the key packaging format. I don't see any
advantage to revisiting either.

We can build any trust model we like with PKIX packaged public keys and the
S/MIME packaging model isn't really a constraint.

The real problems are in UI and in particular key distribution. The model
is not automatic and it should be. I have pushed for using SRV records to
make automated discovery possible but that is not really enough. Perry
Metzeger has pointed out that any mechanism has to be deployable without
administrator intervention (which I have a quibble on, I think the DNS
domain administrator should be able to direct all queries to a lookup of
their choice and block unauthorized sources).

>    could be deployed and end up widely used?

Well His Bruce-ship has made a call for action. Perhaps some of the people
who hear it will write code.

It would be really nice if there was at least one client (e.g. Thunderbird)
that supported encrypted email native without any bolt ins. But even if we
can't do that we can apply security by funneling the outbound traffic
through a SUBMIT proxy that takes an email, sees if it can discover a key
and if so encrypts.

The reason I want to stick with S/MIME is that it means that I don't need
to worry about the other half of the problem. I can free-ride on existing
S/MIME clients for the decryption side of things.

-- 
Website: http://hallambaker.com/

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 07 Sep 2013 20:48:57 +0300

Hi Stephen,

In fact I believe S/MIME is not usable today for economical reasons, 
rather than technical ones.

- Big mail providers are in the business *because* they can snoop your mail.
- They have enough resources to make the user experience of Web mail 
better than that of dedicated email clients, even though from a 
technical point of view this is absurd.
- People are happy with Web mail, and are not interested enough in e2e 
encryption to create a market.
- Thus the sorry state of the market for email certs, as my experiment 
shows.

 From a technical point of view, I think S/MIME is a very good starting 
point.

I have no idea how to break out of the economical bind. I just hope that 
the current situation will create enough demand to inject some life into 
this market.

BTW, S/MIME is not even usable for small enterprises, for two reasons: 
First because you'd need to install the CA cert on all sorts of mobile 
devices, which is hard when you don't have dedicated IT. And second, 
because you don't want an email that you send outside the enterprise to 
generate scary "unknown certificate" warnings on the recipient's client.

S/MIME with DANE would alleviate this problem if organizations were 
allowed to generate their own certificates, including email certs, and 
have them chained to the DNS root of trust. I don't know if DANE 
supports this usage scenario by default.

Thanks,
	Yaron

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 7 Sep 2013 15:57:52 -0400

On Sat, Sep 7, 2013 at 1:48 PM, Yaron Sheffer <[email-masked]> wrote:

> better than that of dedicated email clients, even though from a technical
> point of view this is absurd.
> allowed to generate their own certificates, including email certs, and have
> them chained to the DNS root of trust. I don't know if DANE supports this
> usage scenario by default.
>

DANE and any DNS based scheme is going to require a level of administrative
action that is infeasible for a per-user based approach.

DANE with STARTTLS is very different because the mail server DANE records
can be configured at the same time as the MX, SPF and DKIM records.

---

From: James Cloos <[email-masked]>
Date: Sun, 15 Sep 2013 12:58:29 -0400

>>>>> "YS" == Yaron Sheffer <[email-masked]> writes:

YS> S/MIME with DANE would alleviate this problem if organizations were
YS> allowed to generate their own certificates, including email certs,
YS> and have them chained to the DNS root of trust. I don't know if DANE
YS> supports this usage scenario by default.

draft-ietf-dane-smime-02.txt exists.

Webfinger may be a better choice, though.  It is defined in
draft-ietf-appsawg-webfinger-18.txt.

Details on how to store public keys in webfinger are not yet specified
in any draft, afaics.

Dane tlsa records of course can be used to secure the the webfinger uri.

If one does that, the steps to find or verify an smime or pgp public key
include:

  Convert the email address to a webfinger uri

  Do the a/aaaa and tlsa lookups on the hostname in that uri

  If those dnssec-verify, retrieve the uri

  Find the public key (or a link to the public key) in the json reply

The trust path, then, is rooted with the DS record for the dns root,
follows the dnssec path to the rrsigs for the a/aaaa and tlsa records
for the webfinger uri and trusts the content of the data retrieved from
the uri on the basis that it trusts the location of the uri.

That seems a bit brittle, but not any worse than trusting a path from
some random ca of which one has never heard.  Or a path through a WoT
involving names/identifiers with which one is not familiar.

And http serves large blobs better than dns does.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 15 Sep 2013 21:08:08 +0300

Hi Jim,

I agree that storing users' public keys in DNS is weird.

But I also wonder about your proposal: it sounds like you're putting the 
entire organization's list of employees on a public Web server.

Wouldn't the following be simpler and more natural than both proposals:

- The organization maintains its own CA, maybe just for S/MIME client certs.
- The CA cert is kept as a DNS record, signed by DANE.
- The CA cert is usage-limited, so it can be used for S/MIME only, and 
only for addresses at this particular domain. [I suppose this is the 
hard part. Is it allowed by X.509?]

Advantages:

- This would leave S/MIME unchanged.
- The cert validation code remains a combination of normal trust chain 
processing plus DANE.
- No privacy issues: certificates are not published anywhere.
- Users are managed within the organization, with widely available tools.

Thanks,
	Yaron

---

From: Karl Malbrain <[email-masked]>
Date: Sun, 15 Sep 2013 22:45:26 -0700 (PDT)

Yaron,
 
From what I've learned about DANE, domain owners can publish their own self-signed server certificate through the DNS system.  By using TLS strong authentication, the S/MIME client doesn't need to have the server's certificate checked against a CA. Rather the S/MIME  layer needs to match the DANE delivered certificate with the certificate sent by the server during the TLS negotiation. This is a very small change to the S/MIME to TLS protocol layer interface to query from TLS the server certificate presented, and a similar change to the SMTP to S/MIME interface to pass along the DANE delivered certificate along with the server IP address.
 
Unfortunately, I'm not a TLS nor an S/MIME expert so I can't specify the exact interface changes needed to utilize strong authentication in the TLS interface to S/MIME, or the SMTP interface to S/MIME. Perhaps someone who knows what they are talking about in this area can help.
 
Karl Malbrain

________________________________
 From: Yaron Sheffer <[email-masked]>
To: James Cloos <[email-masked]> 
Cc: [email-masked]; Stephen Farrell <[email-masked]> 
Sent: Sunday, September 15, 2013 11:08 AM
Subject: Re: [perpass] Why Yaron can't encrypt: S/MIME in the real world

Hi Jim,

Advantages:

Thanks,
    Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 16 Sep 2013 10:26:40 +0300

Hi Karl,

I don't understand how this relates to TLS. S/MIME traffic is 
self-protected and does not need to be transported over TLS. S/MIME is 
also independent of SMTP.

But yes, if you can store a self-signed *CA* certificate in your DNS 
zone, then you should be able to pull it off.

Thanks,
	Yaron

On 09/16/2013 08:45 AM, Karl Malbrain wrote:
> Yaron,
>  From what I've learned about DANE, domain owners can publish their own
> self-signed server certificate through the DNS system.  By using TLS
> strong authentication, the S/MIME client doesn't need to have the
> server's certificate checked against a CA. Rather the S/MIME  layer
> needs to match the DANE delivered certificate with the certificate sent
> by the server during the TLS negotiation. This is a very small change to
> the S/MIME to TLS protocol layer interface to query from TLS the server
> certificate presented, and a similar change to the SMTP to S/MIME
> interface to pass along the DANE delivered certificate along with the
> server IP address.
> Unfortunately, I'm not a TLS nor an S/MIME expert so I can't specify the
> exact interface changes needed to utilize strong authentication in the
> TLS interface to S/MIME, or the SMTP interface to S/MIME. Perhaps
> someone who knows what they are talking about in this area can help.
> Karl Malbrain
>
> *From:* Yaron Sheffer <[email-masked]>
> *To:* James Cloos <[email-masked]>
> *Cc:* [email-masked]; Stephen Farrell <[email-masked]>
> *Sent:* Sunday, September 15, 2013 11:08 AM
> *Subject:* Re: [perpass] Why Yaron can't encrypt: S/MIME in the real world
>
> Hi Jim,
>
>  >>>>>> "YS" == Yaron Sheffer <[email-masked]
> <mailto:[email-masked]>> writes:
>  >
> [email-masked] <mailto:[email-masked]>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 16 Sep 2013 10:50:54 -0400 (EDT)

On Sun, 15 Sep 2013, Yaron Sheffer wrote:

> - The CA cert is usage-limited, so it can be used for S/MIME only, and only 
> for addresses at this particular domain. [I suppose this is the hard part. Is 
> it allowed by X.509?]

I guess that works although that does not solve things for large user
domains like hotmail.com or gmail.com. Ideally, we would find something
that works there too, without giving the DNS owners the power to change
these. Although I have no idea if that can be done. Something DLV or CT
like comes to mind.

Paul

---

From: Carl Wallace <[email-masked]>
Date: Mon, 16 Sep 2013 11:03:43 -0400

>hard part. Is it allowed by X.509?]

You'd need to write something to limit CA certificates in this manner.
This may just be a matter of writing up processing rules to codify the
recent CAB Forum changes to EKU usage.

---

From: James Cloos <[email-masked]>
Date: Mon, 16 Sep 2013 14:26:52 -0400

>>>>> "YS" == Yaron Sheffer <[email-masked]> writes:

YS> I agree that storing users' public keys in DNS is weird.

YS> But I also wonder about your proposal: it sounds like you're putting
YS> the entire organization's list of employees on a public Web server.

It wasn't my proposal; just another which was posted on the dane list.

YS> Wouldn't the following be simpler and more natural than both proposals:

YS> - The organization maintains its own CA, maybe just for S/MIME client certs.
YS> - The CA cert is kept as a DNS record, signed by DANE.
YS> - The CA cert is usage-limited, so it can be used for S/MIME only, and
YS> only for addresses at this particular domain. [I suppose this is the
YS> hard part. Is it allowed by X.509?]

For orgs which can manage a local CA, doing so is a good idea.  And I'd
suggest they use it for everything which is dane-compatible.  Not just s/mime.

But it doesn't address the question of how correspondents can find a
given address' cert or the org's ca cert.  They'll need the former to
send encrypted mail to the org's users, and the latter to verify sigs.

Well know mappings from an email address to either a dns lookup or to
the web can provide that.  The dane smime draft (like rfc 2538) tries
to the the former.  Webfinger is an example of the latter.

YS> Advantages:

YS> - This would leave S/MIME unchanged.
YS> - The cert validation code remains a combination of normal trust chain
YS> processing plus DANE.
YS> - No privacy issues: certificates are not published anywhere.
YS> - Users are managed within the organization, with widely available tools.

Not publishing certs means that they are unavailable for encrypting
incoming mail or verifying outgoing sigs w/o some prior out of band
exchange.  That is reasonable for some usages, but precludes other
reasonable ones.

-JimC