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
On 09/07/2013 06:00 PM, Stephen Farrell wrote:
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:
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
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
