STEED - Usable end-to-end encryption
ott at mirix.org
Sun Oct 23 18:50:16 CEST 2011
On Fri, Oct 21, 2011 at 01:46:02AM +0200, Marcus Brinkmann wrote:
> On 10/20/2011 10:25 PM, Matthias-Christian Ott wrote:
> > But who are the providers? Except for people who work in computer
> > science, physics or similar fields I don't know people who run their own
> > mail servers or are part of a cooperative. Most other people use a
> > handful of providers who often offer free service in exchange for the
> > loss of privacy or at least some form of semi-targeted advertisement. Do
> > you expect those providers to ruin their business models by implementing
> > this proposal? I wouldn't count on them.
> Maybe. But the only way to fail for certain is by not trying. There are
> other business models and market pressures beside those that you are
> highlighting. It's not easy to predict.
I agree, there are other business models and perhaps there will be
demand for this, but I just summarised the service providers almost all
“non-technical” people I communicate with use.
> > Perhaps the providers could also be forced by law not to implement
> > this, because (if I remember correctly) come countries require that
> > they store at least the header information (including subject, which
> > should also be encryted by the system) for traffic analysis. So in
> > the worst case the providers couldn't implement this without breaking
> > the law (I doubt that citizens could use the system without breaking the
> > law in this situation either, but individuals are often more venturous
> > than organisations).
> STEED is fully compatible with existing mail encryption, so we do not include
> the headers in the plaintext. I am not an expert, but as far as I know the
> regulation usually demands to store connection data that is available, it does
> not ask for data that is not available for whatever reason. I think your
> interpretation of the regulations in that area is overly pessimistic, but I
> could be wrong. Maybe you can verify this?
I'm not aware of any overview of e-mail data rentention, so I don't
have complete picture, but a quick search on EU data retention laws
showed that only SMTP envelope data is officially stored, so at least
in these countries it's not a problem (though I think the subject
should be encrypted as well). Moreover, I agree that as long as the
body and thus the actual contents are not stored there is reason
why a provider could break the law by providing STEED services to
their costumers. Fortunately many countries have laws to garantuee
(at leas in theory) privacy of correspondance and these laws of a
long tradition, so it seems hard to abolish them. However, I see the
possibility that providers could be forced to cooperate with government
agencies, but this would have little impact and would require bigger
efforts to “break” STEED this way (e.g. MITM attacks by publishing
false keys for new contacts).
> > What about making everyone their own provider? The efforts in this
> > direction intiated by Eben Moglen that lead to the FreedomBox and other
> > projects seem to go in the right direction. It doesn't seem to me less
> > realistic than requiring cooperation from providers.
> I think everybody deserves private email communication, not only those who are
> willing to be their own provider. We don't expect people to carry out their
> own snail mail letters either, and the business model of the post office does
> not require spying on the letters.
I agree, but I also talked to people who don't care about privacy
(nothing to hide) and don't understand it. Therefore, it is important
not to rely on the market to provide the means for private e-mail
communication (do it yourself instead of relying on other people to do
> But, we have to go where the users are, and we have to try our best to get the
> providers cooperation. There is no benefit in ignoring them and their users
> just for our convenience.
Let's say you had the opportunity to convince a smaller independent
hosting provider that e.g. sells web hosting, e-mail and resells
internet connectivity, how would you do this? There had to be real
demand and easily installable and maintainable software to convince them
to implement STEED.
Recently I did some search and inquiries on DNSSEC, for which there is
argueably real demands from private and enterprise customers and there
is working software, but only relatively few companies worldwide offer
it and I don't expect it to be widely deployed within the next years.
However, people running their own server have it running or at leas
prepared (waiting for the registras to close the trust chain by
submitting their public key to the registry) for some time now.
> Maybe you are still not convinced. Then let me give you an illustrative
> analogy. (Disclaimer: I am not associated with SawStop or anybody involved,
> nor have I met anybody involved or used their product). An inventor created a
> table saw that can prevent injury by stopping the blade as soon as it is
> touched by human flesh ("SawStop"). According to the inventory, he could not
> get the technology to be marketed by the big table saw companies. His claim
> is that the companies think that by raising the safety measures in the table
> saw, they would be more liable for table saw accidents, which would make them
> subject to litigation. Eventually he created his own SawStop product line.
> Now, after several years, lawmakers and regulators have taken notice and might
> make sawstop like technology mandatory in table saws.
> Now, maybe SawStop is bad technology, maybe it's good. But at least something
> is true: As long as no candidate technology like it exists, the question
> doesn't even come up. That's the state we are at with email encryption.
> Everybody who tried has learned that email encryption is not worth the hassle.
> Everybody who hasn't tried just expects email to be secure and might not even
> be aware that it is not. It's time to change that equation, don't you think?
I agree, but there is a lot to be done. If the technical specification
is done and there is working software, there really hard work just
begins as I tried to demonstrate by taking DNSSEC as an example.
More information about the Gnupg-devel